Вот такую статью нарыл

Честно скажу, оставила она у меня двоякое впечатление.
С одной стороны, дотнет как человеку, который с него и начал, дал мне почву для творчества на многие годы. Как технология безусловно интересная, новая и почти всемогущая. Тем более, что дотнет сейчас меня кормит.
С другой стороны постепенно начинаю ощущать легкое разочарование. К чему тогда все это бесчисленное количество возможностей, если от него производительность страдает? Плюнуть на эти возможности и ограничиться элементарными операциями, к которым сводятся перегруженные методы в .NET? Или не заморачиваться над этим, никто ж с секундомером возле моей программы не стоит? И к чему мелкие нас готовят дальше, чтоб любой, не только программист, смог открыть студию, накидать на форму контролов, выставить им свойства и создать прогу для своих потребностей без единой строчки самописного кода, и неважно, что там в памяти твориться будет?

В общем, слушаю ваши мнения, а также может у кого ссылки есть, как не надо писать код.

любопытная статейка...я где-то раньше подобные встречал..
для меня на данный момент вопрос производительности важен, поскольку большинство своих разработок сейчас веду под Compact Framework и Windows Mobile, а тут с производительностью туго...

если вцелом, думаю проблема действительно важная, поскольку MS хочет сделать программирование для пользователей, а не для программистов...одна у них цель - побольше народу заманить этим и денег соответственно

все имхо

ЗЫ. пасиба за статью, закрою еще пару тормозничков в работе   

Вот еще фишка, документирована она или нет, неизвестно, нашел у Троелсена.
Раньше без всякой задней мысли использовал код:
Так вот, говорит Троелсен, всякое такое присоединение строк приводит к созданию в памяти копии первоначальной строки, к которой прибавляется уже " Second Word". Первичное же значение ожидает сборки мусора. Если работаешь со строками небольшой величины, то это как бы и неактуально. А если выполнить присоединение 1000 раз, еще и строчки длинные? Поэтому, говорит Троелсен, используйте StringBuilder, он и только он работает непосредственно со строкой в буфере. Для меня это было откровением, может и еще кто не знает этого.

По этому поводу читайте Рихтера и MSDN'овские статьи типа "CLR Inside" 
Откровений будет много 
Не думаю что простые юзеры будут способны на большее чем "Хеллоу Ворлд!"
Тенденция идет к разделению процессов написания кода и рисования интерфейса, причем и там  и там без проффессиональной подготовки врядли чего-то можно добиться. У дотнета своя ниша на рынке, там где нужны быстрые алгоритмы и скорость - C++

Согласен 
C# - прежде всего быстрая и довольно качественная реализация поставленной задачи!

Неплохо.
Мне например хочеться сказать, что многое зависит от того как учат программировать.
Если препод в школе Ас, то он нормально преподает и рассказывает что как и почему нужно делать, а потом на примерах использования для решения тех или иных конкретных задач показывает плюсы и минусы того или иного действа. Плюс подробный разбор полетов после выполнения домашних заданий.  Но таких преподов мало. Не зря говорят: "все познается в сравнении". 

А статья полезная.

Добавлено через 7 минут и 47 секунд
В связи вспомнился анектод про методы оперирования гланд.
"типа на международном медицинском конгрессе после того как западные светилы рассказали о каких-то умопомрачительных и супер сложных методиках проведения операций на сердце или мозг,некие отечественные спецы заявили о том, что они разработали новый метод оперирования гланд - через анальное отверстие и афтогеном"

К чему это? Каждую задачу можно решить тремя способами:
- нормально;
- оптимально;
- и через одно место.
Для первого надо представлять как это работает.
Для второго иметь креативное мышление и ОЧЕНЬ хорошо представлять как это работает.
Ну а третье и так понятно, знаний точно не хватает.

Документирована, конечно, более того, встречается на сертификационных экзаменах MS.
Все дело в том, что string immutable (Хотя на самом деле это не совсем так и через unsafe он меняется ;-) ). 
Даже простая фигня вроде s = s.Replace ("bla", "lab") ведет к созданию новой строки 
MS рекомендует использовать StringBuilder, String.Join, String.Format.


Это сообщение отредактировал(а) Baa - 7.11.2007, 16:40

Да, согласен, это немного обидно то что .нет работает не всегда так быстро как бы хотелось, но каждый программист выбирает свое. Иногда нужно чем-то пожертвовать ради таких удобств как автоматическая сборка мусора. Может быть мне так легко об этом говорить, поскольку я практически никогда не работал с другой сборкой мусора   Но многие статьи меня напугали и я не хочу работать с другой  

Статья кажись хорошая. Еще не дочитал - времени не много, но вечером обязательно прочту.

П.С. Хорошего профа по шарпу я представляю себе как такого человека, что может написать офигенно ясный, функциональный и быстрый код. Именно в таком порядке - сначало ясный, потом функц. а потом уже быстрый. Профа по спп я себе представляю как человека который может написать офигенно быстрый и функциональный код. То же именно в таком порядке. И вряд ли он будет ясный   

П.П.С. Вся эта фигня со стрингами, как нистранно сделана для скорости и для економии памяти. Расчитано на то что програмист должен понимать разницу между стрингами и стринг билдером. Простой стринг - он интернованый. То есть два одинаковых стринга в памяти на самом деле есть один объект. По этому его просто нельзя менять - это приведет к непередвиденным результатам. То есть создав:

Получим два указателя на одну область памяти где хранится "Hello world!" Конечно же все это документировано и большинство авторов обращают на это внимание. Советую почитать Рихтера, у него привычка говорить не просто "что" а еще и "как" и "почему" - что намного интересней, и для меня именно это критерий профа.

Это сообщение отредактировал(а) archeg - 7.11.2007, 16:52

А по поводу концепции упрощения интерфейсов, так всё дело в том, что сейчас сроки на разработку программного обеспечения становятся всё меньше и меньше. Единственный способ успевать всё вовремя - иметь хорошую библиотеку классов, чего Майкрософт и старается сделать. Как-то было рассуждение на их форуме, мол, .NET не дает достаточной скорости для общения с COM портом, так этому человеку ответили, что для этого есть С++, а C# нужня для быстрой разработки "корпоративных" приложений.
Сейчас, как и раньше, необходимо правильно выбирать инструмент. Если вы хотите быстроты и 100% контроля, то выбирайте С++, а если хотите делать всё быстро, то тогда C#.

Да, Рихтера осваиваю понемногу, когда время есть.

Думаю, что будут способны, когда кодинг уподобится процессу записи макросов в МС Офис.

Добавлено через 9 минут и 38 секунд
Вообще благодаря классам-заготовкам .NET успеваешь очень много сделать. Ну а с производительностью - в принципе тоже есть время позаниматься, проанализировать, так сказать - ювелирно довести опять же благодаря тому, что много успел раньше. Но - появился резон засесть за С++. Эх, где на все время найти...

Experimenter, 

Не а.
Посмотри на темы в Базах данных.
Многие когда используют дизайнер для датасет потом задают много вопросов а почему то, а почему сё. Потому как студия сама генерит код, а "программер" не понимает какие процессы происходят или должны происходить за кулисами дизайнера чтобы программа показывала нужные данные в нужном месте или при выборе одного в другом месте показывалось ему соответствующее, да еще и сохранялось в БД при изменении. ИМХО

Добавлено через 5 минут и 9 секунд

Я бы предпочел, "поглубжее" вникнуть как работает C# и VB в .NET.Лучше быть специалистом в узкой области, чем ...(нужное подставте сами) широкого профиля. 


Это сообщение отредактировал(а) thomas - 7.11.2007, 18:48

thomas, тоже верно, но нужда заставляет, не то чтобы производительность не устраивала или еще что-то, но вот нужна сейчас библиотека на Си-шарп, работающая с СОМ-приложениями, а без понимания принципов их работы никак. Так что почитываю, заинтересовался. А так конечно, куда ж я без дотнета. Это хлеб мой!
У нас был один такой кадр на работе, сыпал терминами и определениями из ИТ-технологий и программирования так что можно было червяком себя почувствовать, а как до дела дошло - код написал ни к черту, глюк на глюке, баг на баге... Короче, уволился он через три месяца, так ничего и не создав.

а я себе представляю так: 

хороший программер - себе код педалит и тебе педалит. И он, и ты - при деньгах

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

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

статья приколная, только по-моему с сериализацией аффтар слегка загнался.

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

На работе игрался с тестом там где форич и фор - как то у меня вышло что фор заработал медленее форича (или может мне показалось?). Повторить не удалось 

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

З.Ы. Скорость работы не всегда решает