Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Aquila, Вы писали:
A>>Просто другие не парятся и вообще не втыкают, зачем эту байду качать нужно . AVK>Пользователей януса уже заметно больше десятка. А ты вот крах предсказывал.
Разве "заметно больше десятка" это и не есть крах?
Здравствуйте, Aquila, Вы писали:
A>>>Просто другие не парятся и вообще не втыкают, зачем эту байду качать нужно :). AVK>>Пользователей януса уже заметно больше десятка. А ты вот крах предсказывал.
A>Разве "заметно больше десятка" это и не есть крах? :)))
Учитывая, что янус кроме rsdn никому больше не нужен, то считать количество пользователей — это не совсем корректно. надо сравнивать соотношение: сколько активных пользователей им пользуется, а сколько нет.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, МихаилС, Вы писали:
A>>Просто другие не парятся и вообще не втыкают, зачем эту байду качать нужно . МС>Другим надо больше соответствующей литературы и доки читать. МС>Ты много сложных приложений разработал?
Нет.
MC>Мне как программисту .NET дает очень много МС>возможностей один Reflection чего стоит. Как здорово загрузить Assembly, перебрать в ней МС>все классы форм, имеющих какой-то атрибут, создать все необходимые формы и выложить МС>пользователю. Причем все это без какого-либо фигурного траха как это было (и есть), МС>например, с АктивХ.
Объясняю. Если бы я был бы программистом, использующим C# и .Net, то (уверен) мне это тоже бы много чего дало. Однако поскольку я им не являюсь и использую совершенно другие языки, как по работе, так и "для души", то мне от этого ни жарко ни холодно. Смотреть я могу только с пользовательской точки зрения. С нее мне пока ничего хорошего не видно. Рантайм тяжелый, приложения выскакивают с непонятными ошибками. Те, что не выскакивают, с легкостью могут быть заменены менее тяжелыми и гораздо более проверенными. Рантайм не отлажен, поэтому наверняка потребуется скачивать сервис паки. Может для заводов, газет и пароходов — это то, что нужно, но такому простому пользователю как я, .NET пока еще ничего не дал.
>>> Возможно, и даже очень, что браузер должен быть бесплатным. Но речь как раз не о самом браузере, >>> а о том, что MS привязала свою OS к компонентам IE
Это называется повторным использованием кода. Зачем им плодить разные файлы с одним
и тем же кодом?
Вообще удивительно что такие мысли вообще возникают.
MS привязала _СВОЮ_ OS к компонентам _СВОЕГО_ IE.
Ничего, что я _СВОИ_ программы привязываю к _СВОИМ_
компонентам? Можно?
>>> и заставляет других делать так же. IMHO — это плохо.
Меня никто не заставляет вставлять в свои приложения WebBrowserControl.
Просто это красиво, легко, протестировано миллионами пользователей и надежно.
МС>P.S. aka ЗЫЖ: одно в этой ситуации радует, что MS все равно включит эту классную вещь МС>в новые версии виндов. А вам, господа, придется либо смириться, либо переползать на МС>другую ОС.
Да через пять лет-то они же ее отладят (наверное). Полегче будет.
Здравствуйте, AndrewVK, Вы писали:
IK>>Не вижу пока каким образом фреймворк может дать преимущество. AVK>Ну ты попробуй что нибудь написать тестовое.
Да, ты прав, такие вещи на практике проще проверять.
Чем я наверное и займусь в ближайшее время. Блин, чего только от лени не сделаешь .
Здравствуйте, IgorK, Вы писали:
IK>Да, ты прав, такие вещи на практике проще проверять. IK>Чем я наверное и займусь в ближайшее время. Блин, чего только от лени не сделаешь .
Здравствуйте, Aquila, Вы писали:
A>Объясняю. Если бы я был бы программистом, использующим C# и .Net, то (уверен) мне это тоже бы много чего дало. Однако поскольку я им не являюсь и использую совершенно другие языки, как по работе, так и "для души", то мне от этого ни жарко ни холодно. Смотреть я могу только с пользовательской точки зрения. С нее мне пока ничего хорошего не видно. Рантайм тяжелый, приложения выскакивают с непонятными ошибками. Те, что не выскакивают, с легкостью могут быть заменены менее тяжелыми и гораздо более проверенными.
Ты много релизнутого софта под дотнет видел? Я вот только два штука — VS.NET куски и драйвера к паргелии.
Здравствуйте, Aquila, Вы писали:
AVK>>Пользователей януса уже заметно больше десятка. А ты вот крах предсказывал.
A>Разве "заметно больше десятка" это и не есть крах?
Учитывая то что инсталлятор выложен неделю назад нисколько. И больше десятка это очень скромная оценка, точной статистики нет.
Здравствуйте, econt, Вы писали:
E> Итак, если кто знает КОНКРЕТНЫЕ преимущества .NET, пожалуйста напишите.
1. "Жирная" стандартная библиотека
Не надо изобретать велосипед
2. Стандартизация базовых вещей
Знаешь сколько времени уходит на работу и тестирование хотя бы тех же строк в большом проекте, особенно при использовании сторонних библиотек (движков)? Строки бывают (char*, wchar*, TCHAR*, std::string, std::wstring,
LPOLESTR, BSTR, CString, ATL::CString, WTL::CString) и это только верхушка айсберга.
Или на унификацию работы с файлами (fopen, open, OpenFile и т.д.)
3. Верифицируемый (Managed) код
Теперь в случае вот такого кода, ты получишь осмысленное сообщение об ошибке, а не затирание части стека с непонятными глюками
char s[4];
strcpy (s, "Test");
4. Грамотный Stack Trace
Теперь, если тестер нашел ошибку, то ты от него получишь файл с полным описание трасы вызовов, а не невнятный dump памяти и сообщение об Access Violation.
5. Сборка мусора
Не надо задумываться кто и когда будет освобождать память,
а просто писать.
Object MakeNewObject()
{
return new Object();
}
6. Очень простая стыковка нескольких программ/dll-ек, причем можно легко стыковать даже программы/dll-ки на разных языках
7. Нормальная поддержка модулей (что положительно сказывается на уменьшение глюков при компиляции программы с разными библиотеками)
ps
Писать можно еще долго и много. Это только то, что я вспомнил за 5 минут.
Все эти фичи приводят к тому, как тебе правильно AVK заметил, что этап разработки сокращается в 3 раза, этап отладки в 5 раз, стоимость отдельного программиста в 1.5/2 раза.
Здравствуйте, DarkGray, Вы писали:
E>> Итак, если кто знает КОНКРЕТНЫЕ преимущества .NET, пожалуйста напишите.
DG>2. Стандартизация базовых вещей DG>Знаешь сколько времени уходит на работу и тестирование хотя бы тех же строк в большом проекте, особенно при использовании сторонних библиотек (движков)? Строки бывают (char*, wchar*, TCHAR*, std::string, std::wstring, DG>LPOLESTR, BSTR, CString, ATL::CString, WTL::CString) и это только верхушка айсберга.
Если это так, то это действительно здорово! А подробнее этот пункт можно? Или ссылку, где бы рассказывалось о работе со строками. Насколько я понимаю, в Windows есть два типа строк: обычные ANSI и Unicode. Хотелось бы узнать, как можно упростить работу со строками, если нужно использовать и ANSI и Unicode строки.
DG>6. Очень простая стыковка нескольких программ/dll-ек, причем можно легко стыковать даже программы/dll-ки на разных языках
Это не совсем понятно. По-моему и так нет особых сложностей в подключении DLL. Подробнее можно?
DG>7. Нормальная поддержка модулей (что положительно сказывается на уменьшение глюков при компиляции программы с разными библиотеками)
Т.е. каждая программа имеет свой набор компонентов (DLL например)? Даже если одна и та же DLL может использоваться разными программами, все равно каждая программа будет иметь свою копию DLL, я правильно понял?
DG>Писать можно еще долго и много. Это только то, что я вспомнил за 5 минут. DG>Все эти фичи приводят к тому, как тебе правильно AVK заметил, что этап разработки сокращается в 3 раза, этап отладки в 5 раз, стоимость отдельного программиста в 1.5/2 раза.
Вот мне не нравится, что "стоимость отдельного программиста" сокращается... Для заказчика это вероятно хорошо, но для программиста вряд ли.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Aquila, Вы писали:
A>>Объясняю. Если бы я был бы программистом, использующим C#
[...]
A>>заменены менее тяжелыми и гораздо более проверенными.
AVK>Ты много релизнутого софта под дотнет видел? Я вот только два штука — VS.NET куски и драйвера к паргелии.
1) Чего-то помаленьку клепают... На RSDN, вроде, пара ссылок проскальзывала. Да и на сайтах даунлоадерских кое-что тоже скачать уже можно под .NET заточенное (интерпретатор Forth недоделанный, например ).
Здравствуйте, DarkGray, Вы писали:
DG>Здравствуйте, econt, Вы писали:
E>> Итак, если кто знает КОНКРЕТНЫЕ преимущества .NET, пожалуйста напишите. DG>1. "Жирная" стандартная библиотека DG>Не надо изобретать велосипед
В Виндах сейчас и так функций немало.
DG>2. Стандартизация базовых вещей DG>Знаешь сколько времени уходит на работу и тестирование хотя бы тех же строк в большом проекте, особенно при использовании сторонних библиотек (движков)? Строки бывают (char*, wchar*, TCHAR*, std::string, std::wstring, DG>LPOLESTR, BSTR, CString, ATL::CString, WTL::CString) и это только верхушка айсберга.
Это реальная. CString, ATL::CString, WTL::CString — это, конечно, языко- и библиотекозависимая вещь, а вот всякие LPOLESTR, BSTR и т.п... Доставляют немало проблем, когда хочешь реализовать какой-нибудь интерфейс на ассемблере .
DG>Или на унификацию работы с файлами (fopen, open, OpenFile и т.д.)
А здесь-то какая проблема?
DG>3. Верифицируемый (Managed) код DG>Теперь в случае вот такого кода, ты получишь осмысленное сообщение об ошибке, а не затирание части стека с непонятными глюками
Да, ну это "верифицируемый код". Этак, чего гляди, программа себя и модифицировать не сможет.
DG>4. Грамотный Stack Trace DG>Теперь, если тестер нашел ошибку, то ты от него получишь файл с полным описание трасы вызовов, а не невнятный dump памяти и сообщение об Access Violation.
Это полезно.
DG>5. Сборка мусора
DG>Не надо задумываться кто и когда будет освобождать память, DG>а просто писать.
Тоже полезно.
DG>6. Очень простая стыковка нескольких программ/dll-ек, причем можно легко стыковать даже программы/dll-ки на разных языках
Вот здесь я проблемы не вижу. А чем сложны обычные dll? И в чем проблема "разных языков"?
DG>Все эти фичи приводят к тому, как тебе правильно AVK заметил, что этап разработки сокращается в 3 раза, этап отладки в 5 раз, стоимость отдельного программиста в 1.5/2 раза.
Первые два не стоят последнего .
Конечно, некоторые преимущества налицо, но недостатки, похоже, перевешивают.
Здравствуйте, Aquila, Вы писали:
A>В Виндах сейчас и так функций немало.
Удобство их использования, оставляет желать лучшего...
DG>>Или на унификацию работы с файлами (fopen, open, OpenFile и т.д.)
A>А здесь-то какая проблема?
То, что каждая библиотека работающая с потоками ввода-вывода, хочет поток в своем формате (или ссылку на свой класс оболочку) вот и приходится (и то если повезет) создавать поток в памяти, копировать в него данные, делать оболочку над этим потоком, а потом уже его отдавать библиотеке
DG>>3. Верифицируемый (Managed) код DG>>Теперь в случае вот такого кода, ты получишь осмысленное сообщение об ошибке, а не затирание части стека с непонятными глюками
A>Да, ну это "верифицируемый код". Этак, чего гляди, программа себя и модифицировать не сможет.
Модифицировать ты и вправду сябя не можешь, зато можешь сгенерировать новый код (на основе старого или просто из головы), причем ты можешь оперировать не только маш.кодом, а обычными языковыми конструкциями (добавить класс, добавить метод, сложить два числа и т.д., причем все это в рантайте, с автоматической компиляцией кода)
DG>>6. Очень простая стыковка нескольких программ/dll-ек, причем можно легко стыковать даже программы/dll-ки на разных языках
A>Вот здесь я проблемы не вижу. А чем сложны обычные dll? И в чем проблема "разных языков"?
Ты когда нибудь пытался "подружить" Delphi и VC, Visual Basic и Fortran, Java Script и Builder?
Единственная технология для того, чтобы подружить программы/модули/dll-ки написанные на разнообразных языках была COM. Но для COM необходимо было писать очень много оберточного кода.
Сейчас все просто — пишеть модуль на любом языке, поддерживаемом .Net-ом (от Microsoft-а их уже штук 5, от сторонних производителей — где-то уже порядка 50-ти), далее добавляешь Reference на другую сборку(модуль) и все, можешь использовать любой класс, любую функцию из произвольного модуля.
DG>>Все эти фичи приводят к тому, как тебе правильно AVK заметил, что этап разработки сокращается в 3 раза, этап отладки в 5 раз, стоимость отдельного программиста в 1.5/2 раза.
A>Первые два не стоят последнего .
Я имел ввиду, конечно, не программиста, а простого кодера. Программисты, конечно, останутся в цене.
A>Конечно, некоторые преимущества налицо, но недостатки, похоже, перевешивают.
Я тебе советую, преодолеть эти недостатки (обойти их, закрыть на них глаза — первые винды тоже немножко подглюкивали, а сейчас без них некуда...), то же самое из .Net-ом, технология пока молодая, есть детские болезни, но завтра эти глюки поправят, и технология развернется
Здравствуйте, econt, Вы писали:
E>Если это так, то это действительно здорово! А подробнее этот пункт можно? Или ссылку, где бы рассказывалось о работе со строками.
E> Насколько я понимаю, в Windows есть два типа строк: обычные ANSI и Unicode.
По хорошему, в новых виндах остались только Unicode-ные строки, ANSI-строки в основном используются в старых программах.
E> Хотелось бы узнать, как можно упростить работу со строками, если нужно использовать и ANSI и Unicode строки.
А зачем нужны ANSI-строки?
В .Net-е оставили один тип строк — string (это unicode-ная строка). Все программы на .Net-е используют только данных тип. Конечно, если нужно передать/получить строку в каком-либо другом формате (Ansi, base64, Koi8, CP866 и т.д.) "наружу" (в файл, в другую программу и т.д.), то можно легко перекодировать строку в нужный формат (буквально в одну строчку).
E>Это не совсем понятно. По-моему и так нет особых сложностей в подключении DLL. Подробнее можно?
Посмотри мой ответ на сообщение aquila.
DG>>7. Нормальная поддержка модулей (что положительно сказывается на уменьшение глюков при компиляции программы с разными библиотеками)
E>Т.е. каждая программа имеет свой набор компонентов (DLL например)? Даже если одна и та же DLL может использоваться разными программами, все равно каждая программа будет иметь свою копию DLL, я правильно понял?
Да, теперь даже одна и та же программа может загрузить одну и ту же dll-ку, но разных версий (например, мы используем библиотеку A 2.0 и библиотеку B 1.0, но библиотека B, использует A 1.0)
E>Вот мне не нравится, что "стоимость отдельного программиста" сокращается... Для заказчика это вероятно хорошо, но для программиста вряд ли.
Я хотел сказать, что стоимость отдельного простого "кодера" — сокращается, программистов я никоим образом не хотел задевать.
Здравствуйте, DarkGray, Вы писали:
DG>В .Net-е оставили один тип строк — string (это unicode-ная строка). Все программы на .Net-е используют только данных тип. Конечно, если нужно передать/получить строку в каком-либо другом формате (Ansi, base64, Koi8, CP866 и т.д.) "наружу" (в файл, в другую программу и т.д.), то можно легко перекодировать строку в нужный формат (буквально в одну строчку).
В другую программу перекодировать не нужно, есть атрибуты специальные для интеропа.
Здравствуйте, DarkGray, Вы писали:
AVK>>В другую программу перекодировать не нужно, есть атрибуты специальные для интеропа.
DG>Koi8 или cp866 через атрибуты не задашь
Использовать эти кодировки для межпрограммных коммуникаций изврат редкосный.
.
).
.