Re[7]: возможности .NET
От: Alex Axyonov Украина  
Дата: 22.10.04 07:35
Оценка:
GA>> И получается, что я своим кодом (кровью и потом ) кормлю потенциальную армию халявщиков? Кроме того, это сейчас обфускаторы выдают нечто нечитаемое... А потом энтузиасты "утирательства носа мелкософту" напишут тулзы, позволяющие ускорить разбор кода — закономерности всякие откопают, связи будут наглядно показывать и тэ пэ.

VD>МС тут вообще не причем. Они обфускаторы не делают и не используют. Тулзы такие тоже нельзя создать.


Все-таки используют. Не помню точно, но сборки толи Windows SharePoint Services, толи Microsoft SQL Server Reporting Services обфусцированы.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Re[11]: возможности .NET
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 22.10.04 12:11
Оценка:
Здравствуйте, AndrewVK, Вы писали:

MN>>DataRow хранят элементы в виде object;

AVK>DataRow вобще ничего, кроме ссылки на DataColumn не хранит.

Это деталь реализации. В Mono, например, хранит.
Re[8]: возможности .NET
От: VladD2 Российская Империя www.nemerle.org
Дата: 22.10.04 14:09
Оценка:
Здравствуйте, Alex Axyonov, Вы писали:

AA>Все-таки используют. Не помню точно, но сборки толи Windows SharePoint Services, толи Microsoft SQL Server Reporting Services обфусцированы.


Ну, черт его знает. Я пока что не встречал. Даже сборки Лонгхорна нормально декомпилируются.
... << RSDN@Home 1.1.4 beta 3 rev. 206>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: возможности .NET
От: GlebZ Россия  
Дата: 22.10.04 14:24
Оценка:
Здравствуйте, VladD2, Вы писали:

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


GZ>>Задачи сами тебя находят. Например, пришла к нам одна программа одного достаточно известного производителя на NET. Она хоть и конечно сервер, но требовать 1Г оперативной памяти в requariments для работы, это слишком.


VD>Весомый аргумет при выборе языка обучения. Да и гиг на сенодня серьезная пробелма.

Дело в том, что у нас та же функциональность написанная на С++, требует намного меньше ресурсов. Зачем им требуется 1Г для меня загадка. Есть только предположения, что это связано с особенностями ADO.NET. Ситуация описана в контексте вопроса о превликательности продукта.

GZ>>Имеется, конечно, ввиду VB6. Собственно наплевать на то, какими словами ты пишешь for или if или даже наличие foreach. Когда-то я начинал с модульного программирования. Потом прочитал хорошую книгу и начал писать на OOP. Важно что изменились не только стиль программы, изменилось мышление.

GZ>> Потом, я начал писать для Windows 3.1. Прочел хорошую книгу, и сново изменилось мышление.

VD>А у меня все с точностью на оборот. Я сначала начал писать в ОО-стиле на С и потом я нашел С++ который позволял мне присать в этом стиле более просто. Потом я начал писать на С++ в компонетном стиле и использовать разные идиомы вроде ссылок на методы экземпляра. Потом я нашел Шарп который позволил мне делать все тоже самое намного проще и изящьнее.


GZ>> Уже не было проблем с интерфейсом, зато появились чудеса квазимногозадачности. Дальше начал работать на Windows 95+NT, здесь перестройка ума, не была настолько существенной.


VD>Опять же. Я сначал попытался сам написать нкую оконную оболочку (на С) под текстовый режим, а уже потом увидил виндвос. При этом виндовс показался очень понятным и ничего менять в голове не пришлось.


GZ>> Потом появился OLE со всеми причендалами, то же самое.


VD>И опять же. Оле (вренее КОМ) для меня стало методом позволяющим добавить компонентность в мои программы.


GZ>> Потом пересел на ASP. Ты знаешь как трудно привыкать к тому, что у тебя общение с пользователем всего лишь два стрима, response-request. Далее NET...


VD>Нет. Незнаю. АСП для меня выглядело как решение на базе КОМ и КОМ-скриптов.


Называется, померялись животами. Кстати, я никогда не отвергал наследование в рамках компонента, точно так же делал компоненты еще до того как оно проявилось у меня на горизонте. Когда проявилось чисто компонентное программирование (в моем случае это был COM) это была всего лишь констатация некоторого факта.

GZ>>Все эту шнягу, я написал чтобы показать, что окружение первично, а не язык. Нафиг нужен CRL без высокоуровневых библиотек. Запишем высокоуровневые библиотеку как часть платформы, или окружения, как вам будет угодно. Все таки поставка, одна.


VD>Вот опять смешал катлеты с мухами. Язык есть язык. ЦЛР есть ЦЛР. А библиотеки (не поверишь) есть библиотеки. В стандарт шарпа входит описание минимума библиотек без которых язык не мыслим. Но остальные — это средство поддржки программирования для кокретных задач (АСП, Виндовс ГУИ и т.п.) и для изучения программирования, а точнее для правильного понимания, что такое программирование все они ненужны. Ну, ненужно АСП.НЭТ для того чтобы научиться программировать. А вот язык нужен.

Занятно. В данном контексте я с вами соглашусь. Хотя существует 2 вопроса. А что вы подразумеваете под термином научиться программировать? Лично я до сих пор учусь программировать. Всегда найдется интересная сторона на вроде бы уже известных методах. Ну а во вторых, человек учится программировать для решения определенных задач. И в современном мире, разработчики уже разбиты по специализациям (например ASP.NET и(или) WinGUI и(или) ...). Если он знает как построить цикл или как наследуются классы (и даже умеет это делать правильно и по делу), никому он как просто программист не интерен.

GZ>>При C++ я уже написал свое мнение. Что касается Delphi, кому надо, пускай упражняются, но легкого переноса кода не будет,


VD>Ага. Вот только есть. Программы не использующие явной работы с указателями (а это редкость для Дельфи) и компонетнов третьих фирм, без проблем перекомпилируются в менеджед-приложения.

Сразу же скажу, на промышленных системах не редкость, и стандартные компоненты (что в Delphi что в NET) достаточно бедны. Их или сами дописывают, или закупают у третьих фирм. В случае делфы, когда те же компоненты несовместимы даже на двух соседних (не NET) версиях, вообще случай криминальный.

GZ>>Давно, читал, в 2001 году.


VD>Т.е. до того как была выпущена первая версия дотнета, и соотвествено, спецификация шарпа?

Возможно на бete или SDK. Уже не помню. Помню только что на каждом перекрестке утверждалось, что NET решит все ваши проблемы (притом людьми которые его и в глаза не видели). С тех пор ничего не изменилось (надеюсь что ты не из этого числа). Только спецификация практически не изменилась.

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


VD>Кстати, очень советую. Написан текст очень доходчиво и это занятие дает очень много с точки зрения понимания концепции языка.

Занятно, открыл MSDN, Visual C# Language->C# Language Tour. В глаза бросается статья "Comparison Between C++ and C#".

GZ>>Поскольку моей единственной информацией была именно ваша статья, поверю.


VD>Давай лучше на ты. А то тут Вы начинают коворить при переходе на личности.


GZ>> Однако как сильно воздействуют эти изменения. Приведу пример из практики. Делалась программа на С++, использовался ATL, STL. Один программер попросил совета. Не помню в чем была ситуация, но решалась она красиво с помощью создания template. Программер, который писал на ATL, STL, был весьма хороший человек и коллега, как оказалось не умел этого делать. Через некоторое время, то же самое произошло с другим программером, в той же группе. Достаточно поучительный для меня случай был. Каким параметром это измерить?


VD>Сложностью изучения и применения технологии. Шаблоны в С++ стали слишком важной частью языка. Ими уже не решают проблемы дженерик-прграммирования, а натуральным образом модифицируют язык. Такие повороты не для каждого проходят гладко. Александреску сорвал крышу не одного программиста. АТЛ и СТЛ по сравнению с Локи и Бустом все же очень простые библиотеки. Хотя лично мне многое из АТЛ в свое время нравилось.

Согласен

С уважением, Gleb.
Re[14]: возможности .NET
От: VladD2 Российская Империя www.nemerle.org
Дата: 22.10.04 19:10
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>Дело в том, что у нас та же функциональность написанная на С++, требует намного меньше ресурсов. Зачем им требуется 1Г для меня загадка. Есть только предположения, что это связано с особенностями ADO.NET. Ситуация описана в контексте вопроса о превликательности продукта.


Я видел много дотнете-приложений. В том числе и серверных. Они в среднем потребляют больше памяти чем аналогичные нэйтив. Но чтобы гиг в системных требованиях — это действительно уникальный случай.

Однако я предпочту гиг в системных требоаваниях чем сервер написанный на С++. Намного проще купить пору лишних гиг оперативки, чем думать об очередном трудно уловимом баге. Уж больно тяжело отладить объемистый С++-код (особенно если писали его не супер опытные товарищи, коих в принципе мало).

GZ>Называется, померялись животами.


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

GZ> Кстати, я никогда не отвергал наследование в рамках компонента, точно так же делал компоненты еще до того как оно проявилось у меня на горизонте. Когда проявилось чисто компонентное программирование (в моем случае это был COM) это была всего лишь констатация некоторого факта.


И я о том же. Вот дотнет и явился следующим шагом в урпощении работы с компонентами. По сути в дотнете любой класс — это компонент. А ком с его сложностями и заморочками нервно курит в сторонке.

GZ>А что вы


Давай на ты. А то "вы" тут не очень принято. Да и "вы" с маленькой буквы совсем некрасиво. Меня же не двое?

GZ> подразумеваете под термином научиться программировать?


Хороший вопрос.

GZ> Лично я до сих пор учусь программировать. Всегда найдется интересная сторона на вроде бы уже известных методах. Ну а во вторых, человек учится программировать для решения определенных задач. И в современном мире, разработчики уже разбиты по специализациям (например ASP.NET и(или) WinGUI и(или) ...). Если он знает как построить цикл или как наследуются классы (и даже умеет это делать правильно и по делу), никому он как просто программист не интерен.


Ну, это уже не учеба программировать, а скорее самосовершенствование. Хотя с некоторой натяжкой можно сказать и так.

GZ>Сразу же скажу, на промышленных системах не редкость, и стандартные компоненты (что в Delphi что в NET) достаточно бедны. Их или сами дописывают, или закупают у третьих фирм. В случае делфы, когда те же компоненты несовместимы даже на двух соседних (не NET) версиях, вообще случай криминальный.


И тем не менее компоненты тут не причем. Совместимость есть и она очень высокая.

GZ>Возможно на бete или SDK.


СДК возможно. Но в нем нет полной спецификации. Специяикация вышла чуть позже.

GZ>Занятно, открыл MSDN, Visual C# Language->C# Language Tour. В глаза бросается статья "Comparison Between C++ and C#".


МСДН это не то. Полноценную спецификацию берут здесь: http://msdn.microsoft.com/vcsharp/team/language/default.aspx
... << RSDN@Home 1.1.4 beta 3 rev. 206>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.