Здравствуйте, gandjustas, Вы писали:

>>> G>>Метапрограммирование должно быть везде.
>>> S>В рантайме — разве что скрипты компилять. Так они и без него неплохо работают.
>>> Узко мыслите. На F# например можно код на FPGA выполнить. При этом все будет статически типизировано и проверяться при компиляции.
S>>Ну я только рад за разработчиков FPGA, только мне-то что с того?
G>С того что в программе можно computation-intensive задачу положить на видеокарту и радоваться жизни.

вы определитесь в чем вы разбираетесь в F# или в FPGA или в видеокартах, а то смеяться столько вредно для здоровья читателей.

Здравствуйте, Sergey, Вы писали:

S>Т.е., 1 раз для приложения написать конфиг xml-ный — это ужас-ужас, сильно утомляющий программиста?
если бы все в разработке делалось один разщ и навсегда, то вообще не возникало бы потребности в IoC.
Правка многотонных конфигов жутко утомляет. В коде же есть Intellisence, проверка типов и другие радости.


>> S>Большинство когда либо найденных мной бенчмарков говорит об обратном. Равно как и личный опыт применения.
>> Ну так приведите бенчмарки здесь.

S>Ну те естественно уже не найду, канули так сказать в лету. Вот первое что попалось:
S>http://www.tommti-systems.de/go.html?http://www.tommti-systems.de/main-Dateien/reviews/languages/benchmarks.html
там еще вервый фреймворк, и то по некоторым тестам быстрее С# оказывается быстрее C++.

S>http://www.osnews.com/story/5602
Вот по этим тестам видно что математика медленее работает, а IO даже быстрее.
Получается для математики можно написать либу на C++, а для всего остального .NET юзать

S>http://systematicgaming.wordpress.com/2009/01/03/performance-c-vs-c/
Смотрел на код на C# и плакал. Там в как раз испольуется способ грантированно просадить производительность.

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

S>Дело даже не в подмножестве, не заточенный под карту код либо вообще не пойдет, либо будет работать медленне чем на CPU.
Это вы так думаете. F# — функциональный язык. Если использовать чисто функциональный код, то он может быт распараллелен автоматически. На CPU это не всегда целесообразно ибо большие накладные расходы. А на GPU или любых системах, спроектированных для параллельной обработки информации — вполне.
>> Но тем не менее это будет статически типизированынй код.

S>А с CUDA это по твоему какой код будет?
Не такой. Можно будет код для CUDA выполнить без CUDA?

S>И че, Paint.NET умеет делать хотя бы 10% от того, что умеет фотошоп? И в котором месте тормозит фотошоп?
paint.NET умеет 80% т того что умеет фотошоп.
Фотошоп тормозит везде по сравнению с Paint.NET. Только фильтры в фотошопе работыют быстрее, наверное потому что не через GDI+.


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

Здравствуйте, SleepyDrago, Вы писали:

SD>Здравствуйте, gandjustas, Вы писали:

>>>> G>>Метапрограммирование должно быть везде.
>>>> S>В рантайме — разве что скрипты компилять. Так они и без него неплохо работают.
>>>> Узко мыслите. На F# например можно код на FPGA выполнить. При этом все будет статически типизировано и проверяться при компиляции.
S>>>Ну я только рад за разработчиков FPGA, только мне-то что с того?
G>>С того что в программе можно computation-intensive задачу положить на видеокарту и радоваться жизни.

SD>вы определитесь в чем вы разбираетесь в F# или в FPGA или в видеокартах, а то смеяться столько вредно для здоровья читателей.

Он читает пресс релизы Майкрософт — а это уже о чем то да говорит

Здравствуйте, Denys V., Вы писали:

DV>Здравствуйте, gandjustas, Вы писали:

S>>>Угу, и JVM само по себе тормозить не умеет. Однако конечные продукты вполне тормозят.
G>>CLR — не JVM. Также как и программы на C++ тормозят. Смотри пример Photoshop vs Paint.NET.

DV>Давайте больше ну будем приводить этот пример. Ибо Paint.Net и Photoshop это моська и Слон.
А вы Paint.NET видели? Photoshop — реально слон, очень тормозной.

DV>Даже сложность интерфейса несравнима, не говоря уже об функционале.
Функционал paint.NET покрывает более 80% необходимостей непрофессионального рисования.
Интерфейс у них очень похожий.

DV>так... маленькая ремарка, открыл одну и ту же картинку в обеих... сделал пару мазков брашем и там и там...
DV>Paint.Net занял в памяти 60 Мб
DV>Photoshop 120 Мб

DV>Но ведь даже интерфейса открытого и сложности в нем меньше в намного больше раз чем в 2 раза.
DV>Так что не нужно сравнивать несравнимое. Ненужно. Я с радостью посмотрю на примеры — но этот — несостоятелен!!!
А какая разница, если на одинаковых операциях (кроме фильтров) фотошошоп тормозит сильнее Paint.NET.

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

Здравствуйте, SleepyDrago, Вы писали:

SD>Здравствуйте, gandjustas, Вы писали:

>>>> G>>Метапрограммирование должно быть везде.
>>>> S>В рантайме — разве что скрипты компилять. Так они и без него неплохо работают.
>>>> Узко мыслите. На F# например можно код на FPGA выполнить. При этом все будет статически типизировано и проверяться при компиляции.
S>>>Ну я только рад за разработчиков FPGA, только мне-то что с того?
G>>С того что в программе можно computation-intensive задачу положить на видеокарту и радоваться жизни.

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

Здравствуйте, gandjustas, Вы писали:

G>А вы на ГОЛОМ С++ пишете?

На С++ имеется НАМНОГО больше разных бесплатных кроссплатформенных библиотек и фреймворков, чем на C#. Например для GUI кроме Qt ещё есть FL Toolkit, Ultimate, wxWidgets, FOX, VCF, ... вот вам огромный список: http://www.geocities.com/SiliconValley/Vista/7184/guitool.html

Вот ещё хороший список бесплатных многофункциональных кроссплатформенных библиотек: http://www.nbrains.net/php/pukiwiki/index.php?link%BD%B8%2F%A5%E9%A5%A4%A5%D6%A5%E9%A5%EA%B7%CF%2FC%2B%2B#Container_CLang

G>Наверное они такие заклятые враги, что даже пригласили выедущего разработчика Mono на PDC в качестве докладчика.

Это событие — результат соглашения с Novell. Так что скажите спасибо представителям Новелла за это.

On November 2, 2006, Microsoft and Novell announced a joint agreement whereby Microsoft agreed to not sue Novell’s customers for patent infringement. According to Mono project leader Miguel de Icaza, this agreement extends to Mono but only for Novell developers and customers. It was criticized by some members of the free software community because it violates the principles of giving equal rights to all users of a particular program.

A>>Патенты на C#/CLI принадлежат Microsoft, и до сих пор ведутся споры насчёт допустимости риска ради использования Mono.
G>С# стандартизован ECMA и никому не пренадлежит. Также ECMA стандартизировала спецификацию CLR.
G>Так что ваши слова — откровенный бред.

Пожалуйста, вот вам источники: http://ru.wikipedia.org/wiki/Mono
и http://www.gnome.org/~seth/blog/mono (Why Mono is Currently An Unacceptable Risk)

A>>Но от самой политики Microsoft это не спасёт. А какая политика у этой компании уже все знают — непредсказуемость и "кидалово". И даже вы это здесь подтверждаете:
G>>>А MS чтобы держаться на плаву надо придумывать что-то новое.
G>Выход любого нового продукта анонсируют за год-два. Причем вместе с тупой рекламой предоставляют возможности будущим пиользователям бесплатно пользоваться продуктом во время тестирования

То есть, вы хотите сказать, что не всё так уж и плохо. Потому что у Майкрософт — кидалово с анонсом.
Наверное если сейчас хорошо потренироваться, то потом можно будет даже научиться прогнозировать очередные циклы.

G>Те кто с свое время перешаело на VB.NET не прогадали.

А те кто в свое время перешли на С++ сейчас продолжают спокойно работать. Потому что им гадать вообще не надо. У них уже всё угадано.

A>>Не спорю, маркетинг-пиаром для веб-разработки на С++ — просто не кому было заниматься. В результате, многие упустили очень важную деталь — С++ позволяет экономить сотни тысяч (а в последствии миллионы) долларов на вычисительных мощностях серверов.
G>И потратить миллиарды на стоимости разработки

А что программировать под веб это что ли — какая-то ужасно нетривиальная задача?
Принцип работы с FastCGI можно выучить за 2 дня.

A>>И задачи, функциональность ультрабыстрых веб сервисов можно постоянно усложнять без значительного наращивания ресурсов. Это позволяет делать FastCGI в связке с C++.
G>Это в теории, а примеры "ультрабыстрых веб сервисов" есть?

Читать здесь: http://fastcgi.com

Вот ещё: http://sourceforge.net/projects/witty/

Wt is a freely available library and application server that lets C++ programmers write modern web applications using a familiar C++ GUI programming style. Wt then renders the C++ applications to the web browser. Figure 1, for instance, is a running Wt application—a functional look-alike of the GMail composer, fully AJAX enabled, and written entirely in C++ using CSS for the markup.

Figure1:


From a programmer's perspective, the Wt API is similar to those offered by libraries such as Qt, Gtk, wxWindows, and the like. However, instead of rendering widgets to Windows/X11/ windows, Wt incrementally renders the widgets in web browsers. Wt completely hides the underlying web technologies (HTML, AJAX, XML, FastCGI, JavaScript, and DHTML), chooses a rendering and session-management strategy depending on browser capabilities, and deals with browser dialects. Being a native C++ library, web applications developed with Wt typically enjoy greater efficiency and a smaller footprint than Java or Ruby solutions.

Figure2:


G>>>Конечно, MS гораздо выгоднее поддерживать один .NET чем зоопарк из MFC, ATL, WTL и прочего.
A>>Политика майкрософт — это вообще клиника. Там ещё старый зоопарк толком не закончился, а уже начался новый — с совместимостью разных версий .NET фрэймворков.
G> Нету зоопарка. Разные версии FW не зависят друг от друга и могут спокойно сосуществовать на одной машине.

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

G>Ну я много на чем писал, на C# проще всего.

Я рад за вас.

A>>С# по скорости выполнения, пока тоже больше для скриптинга подходит.
G>Повторяйте это чаще — сами поверите. А пока из того что я видел на .NET работает быстрее C++. особенно это касается серверных приложений.

Да-да конечно, "быстрее".

"gandjustas" <67312@users.rsdn.ru> wrote in message news:3252188@news.rsdn.ru...

> S>Т.е., 1 раз для приложения написать конфиг xml-ный — это ужас-ужас, сильно утомляющий программиста?
> если бы все в разработке делалось один разщ и навсегда, то вообще не возникало бы потребности в IoC.
> Правка многотонных конфигов жутко утомляет. В коде же есть Intellisence, проверка типов и другие радости.

Не убедил, в общем. IoC в плюсах, при желании, есть.

>>> S>Большинство когда либо найденных мной бенчмарков говорит об обратном. Равно как и личный опыт применения.
>>> Ну так приведите бенчмарки здесь.
>
> S>Ну те естественно уже не найду, канули так сказать в лету. Вот первое что попалось:
> S>http://www.tommti-systems.de/go.html?http://www.tommti-systems.de/main-Dateien/reviews/languages/benchmarks.html
> там еще вервый фреймворк, и то по некоторым тестам быстрее С# оказывается быстрее C++.
>
> S>http://www.osnews.com/story/5602
> Вот по этим тестам видно что математика медленее работает, а IO даже быстрее.
> Получается для математики можно написать либу на C++, а для всего остального .NET юзать
>
> S>http://systematicgaming.wordpress.com/2009/01/03/performance-c-vs-c/
> Смотрел на код на C# и плакал. Там в как раз испольуется способ грантированно просадить производительность.

Тем не менее, в целом C# по бенчмаркам получается медленнее. И, что мне еще критичней — памяти жрет больше.

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

А смысл? На плюсах критичные по быстродействию места пишут так, что большого количества выделений-освобождений памяти нет.

> S>Дело даже не в подмножестве, не заточенный под карту код либо вообще не пойдет, либо будет работать медленне чем на CPU.
> Это вы так думаете. F# — функциональный язык. Если использовать чисто функциональный код, то он может быт распараллелен автоматически. На CPU это не всегда целесообразно ибо большие накладные расходы. А на GPU или любых системах, спроектированных для параллельной обработки информации — вполне.

А ищё можно написать искуственный интеллект, и он сам за нас программы сочинять будет Без рабочего распаралеливальщика это все фантазии.

>>> Но тем не менее это будет статически типизированынй код.
>
> S>А с CUDA это по твоему какой код будет?
> Не такой. Можно будет код для CUDA выполнить без CUDA?

Конечно можно, только не без CUDA а без видеокарты. А какое это имеет отношение к статической типизации?

> S>И че, Paint.NET умеет делать хотя бы 10% от того, что умеет фотошоп? И в котором месте тормозит фотошоп?
> paint.NET умеет 80% т того что умеет фотошоп.
> Фотошоп тормозит везде по сравнению с Paint.NET. Только фильтры в фотошопе работыют быстрее, наверное потому что не через GDI+.

Ссылки на бенчмарки, показывающие что фотошоп тормозит везде по сравнению с Paint.NET, привести не затруднит?

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

И что с того? Я то про себя говорю, а не про большинство.

> Сколько вы в своей работе используете программ, которым требуется много считать?

Я не понял, ты проценты тормозного софта считать кинулся или продолжаешь доказывать, что памяти мало не бывает и оптимизировать ничего не надо?

Здравствуйте, Anonim12, Вы писали:

A>Здравствуйте, gandjustas, Вы писали:

G>>А вы на ГОЛОМ С++ пишете?

A>На С++ имеется НАМНОГО больше разных бесплатных кроссплатформенных библиотек и фреймворков, чем на C#. Например для GUI кроме Qt ещё есть FL Toolkit, Ultimate, wxWidgets, FOX, VCF, ... вот вам огромный список: http://www.geocities.com/SiliconValley/Vista/7184/guitool.html
Не думаю что огромный список библиоткек — это хорошо. тот кто использует библиотек это хорошо.

A>>>Патенты на C#/CLI принадлежат Microsoft, и до сих пор ведутся споры насчёт допустимости риска ради использования Mono.
G>>С# стандартизован ECMA и никому не пренадлежит. Также ECMA стандартизировала спецификацию CLR.
G>>Так что ваши слова — откровенный бред.

A>Пожалуйста, вот вам источники: http://ru.wikipedia.org/wiki/Mono
A>и http://www.gnome.org/~seth/blog/mono (Why Mono is Currently An Unacceptable Risk)
Статья 2004 года. ИМХО отстала от текущей ситуации.

A>>>Но от самой политики Microsoft это не спасёт. А какая политика у этой компании уже все знают — непредсказуемость и "кидалово". И даже вы это здесь подтверждаете:
G>>>>А MS чтобы держаться на плаву надо придумывать что-то новое.
G>>Выход любого нового продукта анонсируют за год-два. Причем вместе с тупой рекламой предоставляют возможности будущим пиользователям бесплатно пользоваться продуктом во время тестирования

A>То есть, вы хотите сказать, что не всё так уж и плохо. Потому что у Майкрософт — кидалово с анонсом.
A>Наверное если сейчас хорошо потренироваться, то потом можно будет даже научиться прогнозировать очередные циклы.
естественно, или вы планируете всю жизнь на одном и томже C++ писать?

G>>Те кто с свое время перешаело на VB.NET не прогадали.
A>А те кто в свое время перешли на С++ сейчас продолжают спокойно работать. Потому что им гадать вообще не надо. У них уже всё угадано.
Ну не все, выйдет новая серсия стандарта C++ и посыпятся новые библиотеки, теже сложности с изучением и такаяже зависимость от вендоров на первых порах.

A>>>Не спорю, маркетинг-пиаром для веб-разработки на С++ — просто не кому было заниматься. В результате, многие упустили очень важную деталь — С++ позволяет экономить сотни тысяч (а в последствии миллионы) долларов на вычисительных мощностях серверов.
G>>И потратить миллиарды на стоимости разработки

A>А что программировать под веб это что ли — какая-то ужасно нетривиальная задача?
A>Принцип работы с FastCGI можно выучить за 2 дня.
А написать сервис, который держит высокую нагрузку за 2 дня не получится.

A>>>И задачи, функциональность ультрабыстрых веб сервисов можно постоянно усложнять без значительного наращивания ресурсов. Это позволяет делать FastCGI в связке с C++.
G>>Это в теории, а примеры "ультрабыстрых веб сервисов" есть?
A>Читать здесь: http://fastcgi.com
A>Вот ещё: http://sourceforge.net/projects/witty/
Теория мало интересует. А гугл может (вернее мог до кризиса) себе позволить писать хоть на ассемблере.

G>>>>Конечно, MS гораздо выгоднее поддерживать один .NET чем зоопарк из MFC, ATL, WTL и прочего.
A>>>Политика майкрософт — это вообще клиника. Там ещё старый зоопарк толком не закончился, а уже начался новый — с совместимостью разных версий .NET фрэймворков.
G>> Нету зоопарка. Разные версии FW не зависят друг от друга и могут спокойно сосуществовать на одной машине.

A>Разные версии MFC тоже не зависят друг от друга и могут сосуществовать на одной машине. Так вот, точно такой же зоопарк наблюдается и с версиями фреймворков. Только если раньше версии MFC были достаточно хорошо обратно совместимы, то сейчас вопросов по этому же поводу относительно фреймворков — задают намного больше.
Я вот каждый день читаю форумы по .NET вопрос о совместимости задается раз в месяц.

Здравствуйте, Sergey, Вы писали:

>> S>Т.е., 1 раз для приложения написать конфиг xml-ный — это ужас-ужас, сильно утомляющий программиста?
>> если бы все в разработке делалось один разщ и навсегда, то вообще не возникало бы потребности в IoC.
>> Правка многотонных конфигов жутко утомляет. В коде же есть Intellisence, проверка типов и другие радости.

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

S>Тем не менее, в целом C# по бенчмаркам получается медленнее. И, что мне еще критичней — памяти жрет больше.
А где тесты памяти был?

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

S>Ссылки на бенчмарки, показывающие что фотошоп тормозит везде по сравнению с Paint.NET, привести не затруднит?
А вы поставьте и запустите. Миркотесты в таком деле не нужны.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, Denys V., Вы писали:

DV>>Здравствуйте, gandjustas, Вы писали:

S>>>>Угу, и JVM само по себе тормозить не умеет. Однако конечные продукты вполне тормозят.
G>>>CLR — не JVM. Также как и программы на C++ тормозят. Смотри пример Photoshop vs Paint.NET.

DV>>Давайте больше ну будем приводить этот пример. Ибо Paint.Net и Photoshop это моська и Слон.
G>А вы Paint.NET видели? Photoshop — реально слон, очень тормозной.



DV>>Даже сложность интерфейса несравнима, не говоря уже об функционале.
G>Функционал paint.NET покрывает более 80% необходимостей непрофессионального рисования.
Так 80% чем лично я пользуюсь покрывает MS Paint — означает ли это что я могу ставить на одну полку эти 2 продукта???
У меня жена — проффесиональный дизайнер — и paint.NET для неё поделка — не более. Не смешите людей лучше — а то уже честно — живот болит смеяться. Вы даже с очевидными вещами согласиться не можете. Я подозреваю что если б MS Paint был бы на .Net вы б и его без особого зазрения совести сравнили б с Photoshop.

G>Интерфейс у них очень похожий.

Очень похожий — не означает такой же.

Скажем так — он никакой по сравнинию с интерфейсом Photoshop. Я могу долго объяснять вам разницу, но основываясь на вашем поведении в этой теме — это вас нисколько не заденет.

DV>>так... маленькая ремарка, открыл одну и ту же картинку в обеих... сделал пару мазков брашем и там и там...
DV>>Paint.Net занял в памяти 60 Мб
DV>>Photoshop 120 Мб

DV>>Но ведь даже интерфейса открытого и сложности в нем меньше в намного больше раз чем в 2 раза.
DV>>Так что не нужно сравнивать несравнимое. Ненужно. Я с радостью посмотрю на примеры — но этот — несостоятелен!!!
G>А какая разница, если на одинаковых операциях (кроме фильтров) фотошошоп тормозит сильнее Paint.NET.

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

Да я тоже не пользуюсь почти — у меня есть жена.

Здравствуйте, gandjustas, Вы писали:

G>Или вы думаете что в один приекрасный день все бросят писат на C++ и разом перейдут на шарп?

Нет, не думаю. А вот некоторые — уже давно пишут, что "через два-три года" так и будет.

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

Цифры в студию, обсуждать пока нечего — мои тебе (предлагаю перейти на ты) не нравятся, а свои ты не показываешь.

С>>Мои слова подтверждает не смысл этого сообщения (который, совершенно согласен, по сути бредовое), а наличие такого сообщения.
G>Ну на просторах интернета можно много чего найти. На этом форуме можно найти сотни цитат про то что .NET загнется.

Если интересно мое мнение, то я не считаю, что .NET загнется.

Здравствуйте, Denys V., Вы писали:

DV>Здравствуйте, gandjustas, Вы писали:

G>>Здравствуйте, Denys V., Вы писали:

DV>>>Здравствуйте, gandjustas, Вы писали:
S>>>>>Угу, и JVM само по себе тормозить не умеет. Однако конечные продукты вполне тормозят.
G>>>>CLR — не JVM. Также как и программы на C++ тормозят. Смотри пример Photoshop vs Paint.NET.
DV>>>Давайте больше ну будем приводить этот пример. Ибо Paint.Net и Photoshop это моська и Слон.
G>>А вы Paint.NET видели? Photoshop — реально слон, очень тормозной.
DV>>>Даже сложность интерфейса несравнима, не говоря уже об функционале.
G>>Функционал paint.NET покрывает более 80% необходимостей непрофессионального рисования.
DV>Так 80% чем лично я пользуюсь покрывает MS Paint — означает ли это что я могу ставить на одну полку эти 2 продукта???
DV>У меня жена — проффесиональный дизайнер — и paint.NET для неё поделка — не более. Не смешите людей лучше — а то уже честно — живот болит смеяться. Вы даже с очевидными вещами согласиться не можете. Я подозреваю что если б MS Paint был бы на .Net вы б и его без особого зазрения совести сравнили б с Photoshop.
Ну учитывая что фотошоп еще и денег стоит, то только проф. дизайнерам и меет смысл им пользоваться.

G>>Интерфейс у них очень похожий.
DV>Очень похожий — не означает такой же.
DV>
Интерфейс на 99% совпадает с точностью до расположения интсрументальных окошечек.

DV>Скажем так — он никакой по сравнинию с интерфейсом Photoshop. Я могу долго объяснять вам разницу, но основываясь на вашем поведении в этой теме — это вас нисколько не заденет.
Ну объясните. Интсрументы рисования такие же, слои также работают, список undo-redo тоже не сльно отличается.
В чем отличие? В наборе фильтров разве что?

Вы еще не забывайте что над фотошопом немаленькая фирма работает достаточно долго, а Paint.NET сделан в основном энтузиастами и использует далеко неоптимальные низлежащие средства (GDI+).

Здравствуйте, gandjustas, Вы писали:

G>Не думаю что огромный список библиоткек — это хорошо.

Когда есть выбор — это очень хорошо. А у шарперов нет выбора.

A>>Пожалуйста, вот вам источники: http://ru.wikipedia.org/wiki/Mono
A>>и http://www.gnome.org/~seth/blog/mono (Why Mono is Currently An Unacceptable Risk)
G>Статья 2004 года. ИМХО отстала от текущей ситуации.

Вот вам ещё информация: Mono’s implementation of those components of the .NET stack not submitted to the ECMA for standardization has been the source of patent violation concerns for much of the life of the project. In particular, discussion has taken place about whether Microsoft could destroy the Mono project through patent suits. The base technologies submitted to the ECMA, and therefore also the Unix/GNOME-specific parts, may be non-problematic. The concerns primarily relate to technologies developed by Microsoft on top of the .NET Framework, such as ASP.NET, ADO.NET and Windows Forms, i.e. parts composing Mono’s Windows compatibility stack. These technologies are today not fully implemented in Mono
http://en.wikipedia.org/wiki/Mono_(software)

A>>То есть, вы хотите сказать, что не всё так уж и плохо. Потому что у Майкрософт — кидалово с анонсом.
A>>Наверное если сейчас хорошо потренироваться, то потом можно будет даже научиться прогнозировать очередные циклы.
G>естественно, или вы планируете всю жизнь на одном и томже C++ писать?

А вы планируете всю жизнь переучивать одноразовые "технологии" Microsoft ?

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

Не поверите, но код написанный на C как компилировался 20 лет назад, так и сейчас отлично компилируется и работает, при чём в связке с новым стандартом.

И такого жесткого кидалова как у Microsoft никогда не было, и не будет.

G>>>И потратить миллиарды на стоимости разработки

Не понимаю откуда у многих такой необъяснимый страх перед веб сервисами.

Скажите, неужели это всё аж так "сложно" ?

#include "fcgi_stdio.h"
#include <stdlib.h>

void main(void)
{
    int count = 0;
    while(FCGI_Accept() >= 0) {

        printf("Content-type: text/html\r\n"
               "\r\n"
               "<title>FastCGI Hello!</title>"
               "<h1>FastCGI Hello!</h1>"
               "Request number %d running on host <i>%s</i>\n",
               ++count, getenv("SERVER_NAME"));
    }
}

А вот вам ещё пример: A simple multi-threaded FastCGI application

Писать на C++ веб сервисы так же легко как и на PHP (тем более, что там в основном используются библиотеки написанные на C).

А популярность PHP обусловлена тем, что на shared хостингах запрещено запускать бинарники.

"Anonim12" <78684@users.rsdn.ru> wrote in message news:3252228@news.rsdn.ru...

> Вот ещё: http://sourceforge.net/projects/witty/

Кстати, не флейма ради — вы с этой штукой работали? Я правильно понял — оно в рантайме генерирует HTML с жабаскриптом, соответствующие написанному на C++ коду? Т.е., если одновременно 10 юзеров разными данными одинаковую форму заполняют — HTML для юзеринтерфейса 10 раз генерироваться будет? Или, как с GWT, можно сделать чтобы статика шла отдельно, а вся динамика — единожды сгенерированный жабаскрипт на клиенте?

Здравствуйте, gandjustas, Вы писали:

А ты немерли еще не изучил?
А то читаю и кажется мне что год 2004, а ты не gandjustas а Влад

Здравствуйте, gandjustas, Вы писали:

S>>И че, Paint.NET умеет делать хотя бы 10% от того, что умеет фотошоп? И в котором месте тормозит фотошоп?
G>paint.NET умеет 80% т того что умеет фотошоп.
G>Фотошоп тормозит везде по сравнению с Paint.NET. Только фильтры в фотошопе работыют быстрее, наверное потому что не через GDI+.

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

Здравствуйте, Anonim12, Вы писали:

A>Здравствуйте, gandjustas, Вы писали:

G>>Не думаю что огромный список библиоткек — это хорошо.
A>Когда есть выбор — это очень хорошо. А у шарперов нет выбора.
И что, кому-то от этого плохо?

A>Вот вам ещё информация: Mono’s implementation of those components of the .NET stack not submitted to the ECMA for standardization has been the source of patent violation concerns for much of the life of the project. In particular, discussion has taken place about whether Microsoft could destroy the Mono project through patent suits. The base technologies submitted to the ECMA, and therefore also the Unix/GNOME-specific parts, may be non-problematic. The concerns primarily relate to technologies developed by Microsoft on top of the .NET Framework, such as ASP.NET, ADO.NET and Windows Forms, i.e. parts composing Mono’s Windows compatibility stack. These technologies are today not fully implemented in Mono
A>http://en.wikipedia.org/wiki/Mono_(software)
Ну и что? Вы часто видели чтобы MS подавала в суды по таким прцедентам? Обычно МС использует патенты как раз для защиты от умников которые запатентуют ASP.NET или ADO.NET.

A>>>То есть, вы хотите сказать, что не всё так уж и плохо. Потому что у Майкрософт — кидалово с анонсом.
A>>>Наверное если сейчас хорошо потренироваться, то потом можно будет даже научиться прогнозировать очередные циклы.
G>>естественно, или вы планируете всю жизнь на одном и томже C++ писать?

A>А вы планируете всю жизнь переучивать одноразовые "технологии" Microsoft ?
И какие из технологий за последние 5 лет стали "одноразовыми" ?

A>И такого жесткого кидалова как у Microsoft никогда не было, и не будет.
Вас это так сильно обидело?
Не стоит личные обиды на технологии переность, глупо смотрится.

G>>>>И потратить миллиарды на стоимости разработки
A>Не понимаю откуда у многих такой необъяснимый страх перед веб сервисами.
Какой страх, я как раз вебом занимаюсь и не по наслышке знаю чего стоит выдерживание огромной нагрузки.

A>Скажите, неужели это всё аж так "сложно" ?
Не смешите.
Напишите какой-нить блог на этом.

A>А вот вам ещё пример: A simple multi-threaded FastCGI application
О круто.

A>Писать на C++ веб сервисы так же легко как и на PHP (тем более, что там в основном используются библиотеки написанные на C).
A>А популярность PHP обусловлена тем, что на shared хостингах запрещено запускать бинарники.
Думаете только этим? Напишите простенькое приложение, типа доски обявлений на PHP и на C++ и сравните трудозатраты.
Вы не в теме.

Здравствуйте, FR, Вы писали:

FR>Здравствуйте, gandjustas, Вы писали:

FR>А ты немерли еще не изучил?
Еще нет. Сначала питон.

FR>А то читаю и кажется мне что год 2004, а ты не gandjustas а Влад
Через 5 лет буду про Nemerle холивары вести

Здравствуйте, gandjustas, Вы писали:

G>Сообщаю новость. Времена когда память была серьезны ограничением давно прошли.

Времена, когда память была RAM, давно прошли (за подробностями обращайтесь к мегапостам remark-а в "Философии программирования"). Сейчас, с многоуровневым доступом через разные кэши к медленной памяти, чем меньше памяти потребляет программа и чем более последовательно она по ней ходит, тем быстрее она работает. Посему, чем больше памяти отжирает программа, чем чаще промахи мимо кэша, тем дольше программа ждет данных и тем медленее работает.

Конечно, управляемые среды могут противопоставить compacting GC фрагментации памяти в C++. Но в любом случае, сейчас вопросам потребления и работы с памятью придется уделять гораздо больше внимания, чем несколько лет назад.

Здравствуйте, gandjustas, Вы писали:

DV>>>>Здравствуйте, gandjustas, Вы писали:
S>>>>>>Угу, и JVM само по себе тормозить не умеет. Однако конечные продукты вполне тормозят.
G>>>>>CLR — не JVM. Также как и программы на C++ тормозят. Смотри пример Photoshop vs Paint.NET.
DV>>>>Давайте больше ну будем приводить этот пример. Ибо Paint.Net и Photoshop это моська и Слон.
G>>>А вы Paint.NET видели? Photoshop — реально слон, очень тормозной.
DV>>>>Даже сложность интерфейса несравнима, не говоря уже об функционале.
G>>>Функционал paint.NET покрывает более 80% необходимостей непрофессионального рисования.
DV>>Так 80% чем лично я пользуюсь покрывает MS Paint — означает ли это что я могу ставить на одну полку эти 2 продукта???
DV>>У меня жена — проффесиональный дизайнер — и paint.NET для неё поделка — не более. Не смешите людей лучше — а то уже честно — живот болит смеяться. Вы даже с очевидными вещами согласиться не можете. Я подозреваю что если б MS Paint был бы на .Net вы б и его без особого зазрения совести сравнили б с Photoshop.
G>Ну учитывая что фотошоп еще и денег стоит, то только проф. дизайнерам и меет смысл им пользоваться.

G>>>Интерфейс у них очень похожий.
DV>>Очень похожий — не означает такой же.
DV>>
G>Интерфейс на 99% совпадает с точностью до расположения интсрументальных окошечек.

вам видео ролик снять и показать отличия???
у меня 2 продукта запущено на разных мониторах


где ж они одинаковые на 99% то??????????? ГДЕ???????? Неужели не видно что у Photoshop все кастомно а в Paint стандартные виндовые контролы в основном???
Вы не овен по гороскопу случаем, а?


DV>>Скажем так — он никакой по сравнинию с интерфейсом Photoshop. Я могу долго объяснять вам разницу, но основываясь на вашем поведении в этой теме — это вас нисколько не заденет.
G>Ну объясните. Интсрументы рисования такие же, слои также работают, список undo-redo тоже не сльно отличается.
G>В чем отличие? В наборе фильтров разве что?

G>Вы еще не забывайте что над фотошопом немаленькая фирма работает достаточно долго, а Paint.NET сделан в основном энтузиастами и использует далеко неоптимальные низлежащие средства (GDI+).
Ну так и нечего сравнивать несравнимое. Чего ж вы эти продукты в пример тогда ставите? Похоливарить лишний раз???