| Вопрос: Рихтер "Программирование для .NET" | Добавлено: 09.02.06 21:51 |
Автор вопроса:  vito | Web-сайт: softvito.narod2.ru
|
| Ответы | Всего ответов: 47 |
|
Номер ответа: 16 Автор ответа:  vito Разработчик Offline Client Вопросов: 23 Ответов: 879 |
Web-сайт: Профиль | | #16 | Добавлено: 10.02.06 15:21 |
|
Но MS позиционирует .NET как технологию для разработки приложений любых классов.
(Что - то, там они пытались на С# экспериментальную операционку писать) При тормознутости самой технологии - интерпретация, ООП, управление процессом- практически единственный выход, максимально использовать возможности нового железа. Иначе, как аксима- провал. То есть эта технология может выжить, опираясь, в основном, на рост производительности железа. Или, что равнозначно, единствееным способом увеличить быстродействие - оптимально использовать новые возможности. Вторым фактором,но менее важным, являются другие оптимизации. Из всего этого, складывается необходимость интелектуального поведения компилятора. А теперь сделаем, оправданное допущение, что в MS не дураки сидят 
|
||
|
Номер ответа: 17 Автор ответа: HOOLIGAN Вопросов: 0 Ответов: 1066 |
Профиль | | #17 | Добавлено: 10.02.06 16:58 |
|
Ну ещё бы они не позиционировали .net как средство для достижения любых целей. Тогда даже нонешние поклонники не пользовались бы .net'ом
Реклама, реклама и ещё раз реклама. Вот ведь какая штука: для появления чудодейственной технологии никаких предпосылок не было. Она родилась никому не нужная, потому и прозябает до сих пор, по большому счету не оказывая никакой конкуренции другому инструментарию. Если бы её появление было вызвано спросом на такого рода технологию - она бы шла на ура. Т.е появился спрос - и как следствие появилось предложение. В случае с .net все с точностью до наоборот - сначала родили что-то, а потом стали это что-то впаривать, чтобы окупить затраты и получить прибыль. Т.е. предложение появилось при отсутствии спроса. Вот и вся причина непопулярности. |
||
|
Номер ответа: 18 Автор ответа:  ПавелАдминистратор ICQ: 326066673 Вопросов: 368 Ответов: 5968 |
Web-сайт: Профиль | | #18 | Добавлено: 10.02.06 17:23 |
|
То же Рихтер вещает - .NET будет реализован для ВСЕХ платформ!
PE будут работать под Никсами и т.д.! CLR для linux уже разработана при подержке Novell. Она же планирует в ближайшее время (а может и уже) встроить Mono в истрибутив какого-то мегапопулярного дистрибутива linux (вроде бы redhat, точно не помню). Вообще, основное преимущество .NET дает не разрабатываемым на нем проуктам, а самим разработчикам. Разработка ПО ведется гораздо быстрее и комфортнее. С применением среств метапрограммирования, языков DSL, средств рефакторинга и прочего навесного арсенала, в больших количествах разрабатываемого сейчас, эта сторона .NET значительно усиливается. Тут некоторые проводят такую аналогию: бригада строителей может за десяток лет построить отличный храм из лучших пород дерева, не испоьзовав не единого гвоздя. Это красиво, это круто, мастера славятся на века. Но, увы, ничего более полезного они таким образом не построят, да и храмов людям много надо, а всё это делается очень медленно. Или можно взять современную технику, современные материалы, ля разработки арзитектуры использовать системы автоматизированного проектирования, построить за пару лет славный небоскрёб, в котором можно разместить скажем 1000 офисов компаний. Пусть там будут гвозди, зато быстро и эффективно 
|
||
|
Номер ответа: 19 Автор ответа: ПавелАдминистратор ICQ: 326066673 Вопросов: 368 Ответов: 5968 |
Web-сайт: Профиль | | #19 | Добавлено: 10.02.06 17:32 |
|
Насчет производительности... Не знаю, как вы, а я пока не сталкивался
с такими задачами, где критична производительность. Если уж действительно необходимо, что называется, выжать последние милисекунды, то тогда конечно, .NET здесь не помощник. И даже в этом случае гораздо эффективнее реализовать на неуправляемом коде только критичные к производительности участки кода (таких обычно немного, вряд ли в каком-то приложении это будет более 30% всего кода), а остальное сделать на .NET. Да что тут далеко за примером ходить: даже Sharp вчера уверял меня, что модуль коммуникации с HTTP-сервером лучше написать на .NET, а не на C++, потому что в .NET это сделать проще и логичнее, а на C++ много однотонного кода, и еще надо не забывать освобождать памятью На мои заверения, что C++ обеспечит бОльшую производительность, он заверил, что оно того не стоит
|
||
|
Номер ответа: 20 Автор ответа: SharpЛидер форума ICQ: 216865379 Вопросов: 106 Ответов: 9979 |
Web-сайт: Профиль | | #20 | Добавлено: 10.02.06 23:06 |
|
А теперь сделаем, оправданное допущение, что в MS не дураки сидят
--... неужели вы считаете нас бандой свихнувшихся кровожадных психопатов? -- Нет, мы считаем вас бандой хитрых мерзавцев. (c) "Ночной дозор"
CLR для linux уже разработана при подержке Novell. Она же планирует в
Новости читать чаще надо, Novell забила на Линукс, написание Mono себя не окупило, поэтому разработка будет вестись как и раньше, силами энтузиастов. При чем будет их немного - это не wine или cedega, чтобы можно было в игрушки под никсами играть ближайшее время (а может и уже) встроить Mono в истрибутив какого-то мегапопулярного дистрибутива linux
Или можно взять современную технику, современные материалы, ля разработки арзитектуры использовать системы автоматизированного
проектирования, построить за пару лет славный небоскрёб, в котором можно разместить скажем 1000 офисов компаний. Монополия дотнета здесь - фантом, раздуваемый маркетологами Не случайно большая часть приложений сейчас пишется на Java и C++, они ничем не хуже в плане скорости разработки, особенно если учесть, что вместо 20 метрового дистра с FCL, там есть несколько сотен гигабайт годами оттестированного open-source кода, который покрывает не узкий ряд продуктов MS, а почти все существующие технологии и алгоритмы.
Да что тут далеко за примером ходить: даже Sharp вчера уверял меня, что модуль коммуникации с HTTP-сервером лучше написать на .NET, а не
на C++, потому что в .NET это сделать проще и логичнее, а на C++ много однотонного кода, и еще надо не забывать освобождать памятью Почему-то ты пропустил, как я потом признался, почему я так сказал А я сказал, что мне лень писать все, вот я и хочу спихнуть побольше работы на чужие плечи
|
||
|
Номер ответа: 21 Автор ответа: vitoРазработчик Offline Client Вопросов: 23 Ответов: 879 |
Web-сайт: Профиль | | #21 | Добавлено: 11.02.06 00:57 |
|
Павел
CLR для linux уже разработана при подержке Novell. Она же планирует в
ближайшее время (а может и уже) встроить Mono в истрибутив какого-то мегапопулярного дистрибутива linux Какя в этом выгода MS, кручу - верчу, а понять не могу.
Полностью согласен с HOOLIGAN'ом - перепутали причину и следствие. Либо я просто не понимаю, чего хочет MS. Нет теоретически все отлично - .NET ПЫТАЕТСЯ вобрать в себя все лучшее, из накопленного опыта. И такую инициативу можно только приветствовать. У .NET несомненно есть плюсы(именно в NET), но и минусов слишком много. MS однажды пролетела с инетом(был у них такой стратегический просчет), и с тех пор пытается исправить положение. Но инициатива .NET это что-то, пониманию не поддающееся. Или все -таки "Империя наносит последний удар"? До полного господства?? Ну не верю я в Санта Клауса )
|
||
|
Номер ответа: 22 Автор ответа: vitoРазработчик Offline Client Вопросов: 23 Ответов: 879 |
Web-сайт: Профиль | | #22 | Добавлено: 11.02.06 03:36 |
|
Полностью согласен с HOOLIGAN'ом - перепутали причину и следствие.
Либо я просто не понимаю, чего хочет MS. А вот и сам себе противоречу
Необходимость в подобной технологии возникла. Причем потребность огромная. Компьютеры все больше входят в нашу жизнь, а следовательно нужно все больше прграмм. Причем написанных быстро. При нахождении оптимальной величины, время написания <-> производительность ПО, предпочтение отдается сокращению времени. Если вспомнить зачем собственно был создан ООП. Повторное использование кода, легкость расширения и сопровждения... да слышали эту жвачку. (ИМХО) На самом деле причины три. 1. С ростом сложности программ, ООП позволяет лучше стркутурировать листинги, разбивая их на логически объединенные фрагменты. 3. Несколько другой подход к прграммированию, позволяет более легко(для человеческой логики) реализовывать сложные алгоритмы. 2. Возможность управлять процессом разработки в группе. Выделяя логические модули для определенного разработчика в группе. Такой кит ООП как Инкапсуляция, не что иное, как стремление оградить разработчиков в группе от лишней информации(ее и так очень много). И т.д. и т.п. То есть конвейер, удовлетворение потребностей рынка. Но сегодня этого уже мало. Добавим сюда интерпретацию, а не компиляцию (рост производительности кодера), избавим от рутины (выделение- освобожение памяти как наиболее характерный пример), дадим готовые, лучшие, отлично отлаженные алгоритмы, практически на все случаи жизни. Вот требования сегодняшнего рынка, и .NET им отвечает. Это плохо? Нет. Зачем изобретать велосипед снова и снова? Результат - рост производительности, большая свобода творчества(а не рутины). В итоге - подобная технология очень нужна. Может реализация еще оставляет желать лучшего, но это уже вопрос времени. Конечно, все это реализовано в том или ином виде, .NET пытается собрать все вместе. Посмотрим, что получится. Хотя исход, уже практически предрешен. |
||
|
Номер ответа: 23 Автор ответа: SharpЛидер форума ICQ: 216865379 Вопросов: 106 Ответов: 9979 |
Web-сайт: Профиль | | #23 | Добавлено: 11.02.06 04:24 |
|
Повторное использование кода, легкость расширения и сопровждения... да слышали эту жвачку.
(ИМХО) На самом деле причины три. Ты когда-нибудь на ООП писал? Я не имею ввиду ВБ-шное жалкое подобие, а полноценное ООП-приложение с темплейтами, виртуальными методами, конструкторами, множественным наследованием и перегрузкой операторов? Если нет, то зачем его хоронишь, да еще и с таким гробовщиком?
готовые, лучшие, отлично отлаженные алгоритмы, практически на все случаи жизни Алгоритмов в FCL почти никаких нет, по большей части там объекты, инкапсулирующие работу с технологиями МС - от WinAPI до SOAP.
избавим от рутины (выделение- освобожение памяти как наиболее характерный пример)
От выделения памяти никто не освобождал, о освобождение памяти это не рутина, а признак того, что программер хоть немного понимает, что и когда у него создается. |
||
|
Номер ответа: 24 Автор ответа: sneРазработчик Offline Client ICQ: 233286456 Вопросов: 34 Ответов: 5445 |
Web-сайт: Профиль | | #24 | Добавлено: 11.02.06 04:45 |
|
Какя в этом выгода MS, кручу - верчу, а понять не могу.
Кручу - верчу, тебя запутать хочу... (с) где-то было
1. С ростом сложности программ, ООП позволяет лучше стркутурировать листинги, разбивая их на логически объединенные фрагменты.
С ростом сложности программ людям надо научиться хорошо документировать исходный код! Я вот работаю, правлю чужой код... нет не тот что месяц назад до меня кто-то писал, а тот что писали 4-7 лет назад... Документации ноль... и думаете мне чем-то помогает ООП, не смешите меня! 2. Возможность управлять процессом разработки в группе. Выделяя логические модули для определенного разработчика в группе.
Имхо, хватило бы и созлашений... Такой кит ООП как Инкапсуляция, не что иное, как стремление оградить разработчиков в группе от лишней информации(ее и так очень много). И т.д. и т.п.
А вот когда ищешь ошибку (а в больших продуктах они возникают чуть-ли не после каждого серьезного изменения кода одного из модулей) то во всю эту срань приходится влезать и сидеть неделями!!! Добавим сюда интерпретацию, а не компиляцию (рост производительности кодера)
Интерпритатор ничего не прибавляет кодеру, это-лишь головная боль для программера
избавим от рутины (выделение- освобожение памяти как наиболее характерный пример)
С автоматической сборкой мусора не поспоришь, но оно давно уже... и точка этого точно не открыла, хотя и хвастается на право и на нлево
дадим готовые, лучшие, отлично отлаженные алгоритмы, практически на все случаи жизни.
Которые, как ни странно, уже существовали... Вот ведь не задача... И т.д. и т.п.
У автора закончились глупые мысли... Сочувствую ему
То есть конвейер, удовлетворение потребностей рынка.
Хотят посадить за компьютер бабушку божий-одуванчик что тыкала бы на кнопочку, а программеров... верно, куда нам их столько... Бабушкам платить же меньше
Но сегодня этого уже мало.
Свободные бабушки кончились... Вот требования сегодняшнего рынка, и .NET им отвечает.
НЕТ Это плохо? Нет. Зачем изобретать велосипед снова и снова?
Вот она, истина! Результат - рост производительности, большая свобода творчества(а не рутины).
Куда бы поставит ьэту кнопочку, тут она не смотрится, а может сюда? В итоге у сотрудников в пояснительной записке за рабочий день: думала куда ткнуть контрол типа кнопка, сегодня творческий кризис, завтра буду работать над этой проблеммой исчо! В итоге - подобная технология очень нужна.
Кому? Может реализация еще оставляет желать лучшего, но это уже вопрос времени.
7 лет (с первой версии) это не срок... конечно же... Конечно, все это реализовано в том или ином виде, .NET пытается собрать все вместе.
Что именно? Хотя исход, уже практически предрешен.
Провал ?
PS Прошу прщения не сдержался, но какая статья такая и пародия )
Я уже высказал что хотел - каждая тулза для своего дела, и выше головы не прыгнет! |
||
|
Номер ответа: 25 Автор ответа: sneРазработчик Offline Client ICQ: 233286456 Вопросов: 34 Ответов: 5445 |
Web-сайт: Профиль | | #25 | Добавлено: 11.02.06 04:49 |
|
Если нет, то зачем его хоронишь, да еще и с таким гробовщиком?
А ты когда-нибудь переписывал!? Я имею в виду не те программы что убираются в пару метров, а нормальные что пишут на диски!? Так зачем превозносить эту хрень! На каждое чудо можно глядеть из своего угла и по-разному расценивать... |
||
|
Номер ответа: 26 Автор ответа: vitoРазработчик Offline Client Вопросов: 23 Ответов: 879 |
Web-сайт: Профиль | | #26 | Добавлено: 11.02.06 13:14 |
|
Неплохо.
Классически схлестнулись сторонники ООП и притивники. Sharp - я писал с ООП серьезные вещи. Потому знаю о чем говорю. И знаю, зачем все эти формальные структуры и правила, были придуманы. Но заметь я не сазал, что ООП -зло, для каждого случая свое. Иногда я сам предпочитаю такой подход к прграммированию С++, иногда - нет С. Кстати sne практически во всем, был значительно более объективен. sne. 7 лет (с первой версии) это не срок... конечно же...
Так я постами выше, разве не говорил, что за такой срок при такой рекламной компании - провал? А что - ты мне ответил? Хотят посадить за компьютер бабушку божий-одуванчик что тыкала бы на кнопочку, а программеров... верно, куда нам их столько... Бабушкам платить же меньше
В общем ты прав, только возраст здесь не главное )
Тут видишь какая проблема, ТАЛАНТЛИВЫХ (да хоть бы просто толковых) прграммистов мало, а программ нужно много... Ну и цена конечно играет роль. Уж очень страдают фирмы - разработчики от высокой стоимости разработки ПО. По их же словам - точнее словам менеджеров. У автора закончились глупые мысли... Сочувствую ему
Спасибо ) Мыслей и правда было немного
З.Ы. На самом деле в споре рождается истина. То что я немного взбудоражил обществееность, сорри, признаюсь шаг сознательный. Ну что ж, все становится более ясно. |
||
|
Номер ответа: 27 Автор ответа: sneРазработчик Offline Client ICQ: 233286456 Вопросов: 34 Ответов: 5445 |
Web-сайт: Профиль | | #27 | Добавлено: 11.02.06 14:21 |
|
Так я постами выше, разве не говорил, что за такой срок при такой рекламной компании - провал?
А что - ты мне ответил? Ну молчание знак согласия Я проситал, помолчал, согласился, и пошел читать дальше
В общем ты прав, только возраст здесь не главное
) Я имел ввиду навыки
Спасибо
) Мыслей и правда было немного Это хорошо что глупых немного Толковые мысли вытесняют )
З.Ы. На самом деле в споре рождается истина.
Спор стар как .НЕТ )
То что я немного взбудоражил обществееность, сорри, признаюсь шаг сознательный. Ну что ж, все становится более ясно.
От этого ворум только выигрывает
|
||
|
Номер ответа: 28 Автор ответа: ПавелАдминистратор ICQ: 326066673 Вопросов: 368 Ответов: 5968 |
Web-сайт: Профиль | | #28 | Добавлено: 11.02.06 15:03 |
|
Кстати говоря, релиз .Net был в 2002-ом году, значит ему не 7, а 4
года... И кстати, а по каким критериям можно оценять успешность технологии? |
||
|
Номер ответа: 29 Автор ответа: vitoРазработчик Offline Client Вопросов: 23 Ответов: 879 |
Web-сайт: Профиль | | #29 | Добавлено: 11.02.06 15:44 |
|
И кстати, а по каким критериям можно оценять успешность технологии?
По весу ПО разработанного на данной технологии, к общему количеству ПО разработанного в оцениваемый период времени. Попробую резюмировать. В общем .NET провалилась - мнения мое и большинства участников дискурсии( не первый раз, MS уже пыталась создать всеобщую среду программирования) Причины. 1. .NET не привнесла ничего нового, что бы уже не было реализовано. 2. .NET противоречит прежней иделогиии Windows. 3. .NET не обеспечивает удобной совместимости, с уже созданным кодом, основаннным на "старых" технологиях. 4. .NET приложения низко производительны, что исключает ее использование для разработки критичных к производительности приложений. 5 .NET использует жесткий ООП подход к прграммированию, что не приемлют многие разработчики, или что равнозначно, некоторые приложения не позволяют использовать этот подход . 6. .NET в разрезе сетевых технологий терпит крах в силу отсутствия кроссплатформенности (собственн даже не на всех машинах под управлением Windows имеется в наличии необходимая библиотека). 7. .NET не устоялась и находится в процессе развития. В силу этих причин .NET может быть использована только для разработки корпоративного ПО, при условии исползования только операционной системы Windows. Исправляем и добавляем
|
||
|
Номер ответа: 30 Автор ответа: sneРазработчик Offline Client ICQ: 233286456 Вопросов: 34 Ответов: 5445 |
Web-сайт: Профиль | | #30 | Добавлено: 11.02.06 16:15 |
|
И кстати, а по каким критериям можно оценять успешность технологии?
По востребованности ?
Кстати говоря, релиз .Net был в 2002-ом году, значит ему не 7, а 4
года... А как же беты ?
.NET приложения низко производительны, что исключает ее использование для разработки критичных к производительности приложений.
Я понимаю что тут сейчас начнется, но это доказано На отдельно взятых задачах работа точки не так шустра как ее создателям хотелось бы этого )
(VB6 тут конечно вообще вне конкуренции) 8. Я не люблю когда меня ограничивают... Если у меня массив byte и я желаю их куском скопировать/перенести за раз, либо же конвертировать в DWORD байты с 5-го по 8-й... и мне не дают этого сделать, обоснованием служит, мол вы что же!? так нельзя... Меня это бесит Я сам лучше знаю что у меня там внутри массива и как мне с этим обращаться!
|
||