Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 50
Ура, еще 4 человека используют .net 1.1 Я не одинок в своем кошмаре!
С версии 1.1 прошло 10 лет же. Сбербанк что ли?..
А я ещё поначалу сомневался, стоит ли включать 1.0 и 1.1 в опрос.Ладно хоть, что 1.0 пока на нуле. Уже нет.
А я ещё поначалу сомневался, стоит ли включать 1.0 и 1.1 в опрос.
В некоторых местах до сих пор используются комптютеры класса Pentium 1-2 с Windows 98 (почему бы и нет, если задача — печатная машинка с пасьянсом). Иногда может быть надо что-то написать для такой конторы. Вот 1.1 и живёт. Да что там, даже VisualBasic 6 живёт и турбопаскаль досовский.
А ещё есть фирмы, которые один раз разработали программу, кое как решающую специализированную задачу, для которой нет существенных конкурентов, понаподсадили на неё клиентов и всю жизнь поддерживают, почти не развивая. Я лично знаю одну очень популярную у нас специализированную учётную программу, представляющую из себя весьма своеобразное поделие на Visual FoxPro, и авторы не плохо живут, заставляя клиентов регулярно продлевать лицензии. В таких проектах основной принцип «не меняй то, что работает», вот мы и видим 55+32 человек, не переходящих на новую версию фрэймворка никогда. И, в принципе, ничего особо зазорного в этом нет, просто бизнес. Задача есть, решение есть, все довольны (хотя, иногда, и не без матов в процессе эксплуатации).
А ещё есть фирмы, которые один раз разработали программу, кое как решающую специализированную задачу, для которой нет существенных конкурентов, понаподсадили на неё клиентов и всю жизнь поддерживают, почти не развивая. Я лично знаю одну очень популярную у нас специализированную учётную программу, представляющую из себя весьма своеобразное поделие на Visual FoxPro, и авторы не плохо живут, заставляя клиентов регулярно продлевать лицензии. В таких проектах основной принцип «не меняй то, что работает», вот мы и видим 55+32 человек, не переходящих на новую версию фрэймворка никогда. И, в принципе, ничего особо зазорного в этом нет, просто бизнес. Задача есть, решение есть, все довольны (хотя, иногда, и не без матов в процессе эксплуатации).
Я вполне допускаю, что такие «застрявшие в прошлом» конторы существуют, но не могу понять, зачем добровольно соглашаться на поддержку и развитие подобного софта, если приходится постоянно плеваться на процесс разработки. По-моему, полезнее для нервов найти место, где можно разрабатывать на более современных продуктах. Да и неприятно, наверное, осознавать, что живёшь с опозданием на 10 лет.
.Net 1.1 не так уж страшна, простые вещи на ней пишутся, по большому счёту, почти точно так же, как и в более новых.
Да и неприятно, наверное, осознавать, что живёшь с опозданием на 10 лет.
Почему же. Лично я умудряюсь совмещать любовь и азарт в отношении новейших языков и технологий с буйной некрофилией — обожаю антикварное железо (особенно девайсы, считавшиеся когда-то очень давно очень крутыми) и применять его к решению практических задачь.
может вы с ними в одном проекте работаете? =)
+1 за перечисление фич!
В смысле WinForms, WPF, ASP.NET и так далее? Мне слабо всё перечислить. :) Плюс есть куча вещей, которые непонятно, включать ли: IronPython (разрабатывался MS, потом забыт), Unity (в сам фреймворк не входит, но на совести MS) и т.п.
А можно я чуточку поправлю?
В описании фич немного смешаны, собственно, фичи фреймворка, и фичи языка.
Ну вот например, в языке C# 4.0 есть фича «параметры по умолчанию». А компилить его можно под .NET 2.0. У нас, кстати, есть такой продукт (виндовая утилита, коммерческая) — пишем его на C# 4.0 но компилим код под 2.0, т.к. хотим максимальной совместимости…
А вообще вот полезная ссылка для тех кто пишет десктопные утилиты: www.statowl.com/microsoft_dotnet.php
В описании фич немного смешаны, собственно, фичи фреймворка, и фичи языка.
Ну вот например, в языке C# 4.0 есть фича «параметры по умолчанию». А компилить его можно под .NET 2.0. У нас, кстати, есть такой продукт (виндовая утилита, коммерческая) — пишем его на C# 4.0 но компилим код под 2.0, т.к. хотим максимальной совместимости…
А вообще вот полезная ссылка для тех кто пишет десктопные утилиты: www.statowl.com/microsoft_dotnet.php
Ну понятно, что там всё в одну кучу без разбора. Это для оценки с высоты птичьего полёта. Не вижу большой пользы разбирать в этом списке, какие версии версий фреймворка, какие версии какого языка, как они взаимосвязаны, к каким осям в каком виде прилагаются, с какими средам разработки вышли, что с чем обратно и вперёд совместимо и т.п. Да и во всём этом много тёмных мест: тот же async/await в одной версии доступен из коробки, в другой с библиотекой, та же история с TPL и многим другим.
Мне не только лень, но и слабо разобрать всё это по полочкам — в конце концов я сам пользуюсь малой частью фреймворка.
Мне не только лень, но и слабо разобрать всё это по полочкам — в конце концов я сам пользуюсь малой частью фреймворка.
В градации «Как быстро вы переходите на новую версию» не хватает оторванных от времени пунктов. Например, из-за наличия таких фич как generics и Edit and Continue в 2.0 я на нее сразу и пересел, а вот на более поздние версии переезжаю гораздо медленнее.
Стараюсь не использовать вообще, кроме как для сторонних приложений. Когда есть возможность писать на Си, предпочитаю его.
И в чем дзен?
Логичнее же наоборот, когда никак по-другому нельзя — писать на более низкоуровневых C/C++.
Логичнее же наоборот, когда никак по-другому нельзя — писать на более низкоуровневых C/C++.
Для меня важно удобство пользования, а не написания. Обычному пользователю всё равно, написано ли приложение на ассемблере или на прологе. Ему не важно, использовал ли разработчик всякие MVC, или он писал полностью в процедурном стиле. Зато его жутко бесят тормоза. Тормоза во время запуска из-за компиляции промежуточного кода в машинный. Тормоза во время работы из-за сборки мусора. Причём тормоза эти не от сложности алгоритмов или низкой производительности аппаратного обеспечения, а от того, что так кодер (или менеджер) захотел. И если при компиляции в машинный код тормоза можно проконтролировать, то в случае с .NET и Java многое зависит от того, как себя виртуальная машина поведёт. А утечки памяти и переходы по нулевому указателю на язык не надо сваливать, надо писать так, чтобы по логике программы их не было, да и на языках высокого уровня при желании можно их создать.
Тормоза во время запуска обычно не превышают пары секунд.
«Компиляция» IL в машинный код происходит только один раз при первом запуске (или даже можно сделать, что при установке).
Тормоза во время работы из-за сборки мусора в прикладном приложении — это признак очень плохого программиста. За 5 лет такого ни разу не видел. Вот в высоконагруженных «серверных» приложениях — возможно, но для исключения таких ситуаций есть специальные техники.
«Компиляция» IL в машинный код происходит только один раз при первом запуске (или даже можно сделать, что при установке).
Тормоза во время работы из-за сборки мусора в прикладном приложении — это признак очень плохого программиста. За 5 лет такого ни разу не видел. Вот в высоконагруженных «серверных» приложениях — возможно, но для исключения таких ситуаций есть специальные техники.
У вас какие-то странные представления об управляемом коде.
В C# приложении эти тормоза происходят ровно один раз — при первом запуске. И, скажем, лишние пять секунд запуска я не замечу (да даже Word может грузиться в пять раз больше, чем будет идти компиляция). В Java приложении интерпретация, плавно переходящая в компиляцию, поэтому теоретически проблемы первого запуска быть не должно вообще, но я ни программирую на Джаве, ни пользуюсь написанными на ней десктопными приложениями, поэтому точно сказать не могу.
Кроме того, можно заранее скомпилировать приложение во время установки, если первый запуск настолько критичен. Учитывая, что во время любой установки создаются точки восстановления системы, добавление десятка секунд в установку гарантированно никто не заметит.
Чтобы ощутить тормоза сборщика мусора в дотнете, нужно очень постараться, скажем, генерировать по 10 метров мусора каждую секунду. В обычном приложении вы этого никогда не заметите. Сборка мусора происходит в несколько поколений, и в случае десктопных приложений сборка происходит в отдельном потоке. Дотнет всегда славился отличным сборщиком мусора, ещё с первой версии.
За Джавой не следил, там был блокирующий сборщик, и всякие убивания роботов об стену на совести Джавы, но там последнее время происходили какие-то телодвижения, поэтому как там сейчас обстоят дела — не знаю.
Ну отнимет сборщик мусора у вас 5% времени. И что с этого? Некоторые алгоритмы за счёт сборщика мусора вообще ускоряются относительно плюсов (если не использовать специализированных аллокаторов).
Тормоза контролируются профилировщиками, как и во всех нормальных средах разработки для всех нормальных языков. И при остром желании в машинный код тоже можно залезть, там ничего мифического.
Понимаете, какое дело… Управляемый код — это не только лучшая защищённость от ошибок, не только более высокая скорость разработки, но, как это ни парадоксально, зачастую более высокое качество результата. Если посадить новичков писать на плюсах и на шарпе, то у плюсовика получится неработающая фиговина, а у шарповика будет что-то шевелиться. Если середнячка — в плюсах будет глючная тормозная поделка, а в шарпе будет стандартная средняя программа.
Где плюсы рулят — это там, где реально критична скорость выполнения кода (игровые движки, железо, сложные расчёты и т.п.), где есть крутые специалисты, которые реально знают, что и зачем делают, а не гонятся за мини-оптимизациями. На плюсах потолок скорости исполнения кода — выше, чем на шарпе. Но этот потолок нужен в лучшем случае 1% приложений. И цена этого потолка — раз 10 больше, чем цена управляемого кода на 20-30% медленнее. И потолок недостижим для большинства компаний, где все — середнячки или продвинутые середнячки.
Поэтому, если вы занимаетесь разработкой в областях, где скорость нужна, и делаете это качественно — я вас уважаю. Если вы пишете на плюсах бизнес-приложения и прочий ширпотреб, где 90% процессорного времени отнимает GUI — то выбор плюсов ошибочен.
Тормоза во время запуска из-за компиляции промежуточного кода в машинный.
В C# приложении эти тормоза происходят ровно один раз — при первом запуске. И, скажем, лишние пять секунд запуска я не замечу (да даже Word может грузиться в пять раз больше, чем будет идти компиляция). В Java приложении интерпретация, плавно переходящая в компиляцию, поэтому теоретически проблемы первого запуска быть не должно вообще, но я ни программирую на Джаве, ни пользуюсь написанными на ней десктопными приложениями, поэтому точно сказать не могу.
Кроме того, можно заранее скомпилировать приложение во время установки, если первый запуск настолько критичен. Учитывая, что во время любой установки создаются точки восстановления системы, добавление десятка секунд в установку гарантированно никто не заметит.
Тормоза во время работы из-за сборки мусора.
Чтобы ощутить тормоза сборщика мусора в дотнете, нужно очень постараться, скажем, генерировать по 10 метров мусора каждую секунду. В обычном приложении вы этого никогда не заметите. Сборка мусора происходит в несколько поколений, и в случае десктопных приложений сборка происходит в отдельном потоке. Дотнет всегда славился отличным сборщиком мусора, ещё с первой версии.
За Джавой не следил, там был блокирующий сборщик, и всякие убивания роботов об стену на совести Джавы, но там последнее время происходили какие-то телодвижения, поэтому как там сейчас обстоят дела — не знаю.
Ну отнимет сборщик мусора у вас 5% времени. И что с этого? Некоторые алгоритмы за счёт сборщика мусора вообще ускоряются относительно плюсов (если не использовать специализированных аллокаторов).
И если при компиляции в машинный код тормоза можно проконтролировать, то в случае с .NET и Java многое зависит от того, как себя виртуальная машина поведёт.
Тормоза контролируются профилировщиками, как и во всех нормальных средах разработки для всех нормальных языков. И при остром желании в машинный код тоже можно залезть, там ничего мифического.
Понимаете, какое дело… Управляемый код — это не только лучшая защищённость от ошибок, не только более высокая скорость разработки, но, как это ни парадоксально, зачастую более высокое качество результата. Если посадить новичков писать на плюсах и на шарпе, то у плюсовика получится неработающая фиговина, а у шарповика будет что-то шевелиться. Если середнячка — в плюсах будет глючная тормозная поделка, а в шарпе будет стандартная средняя программа.
Где плюсы рулят — это там, где реально критична скорость выполнения кода (игровые движки, железо, сложные расчёты и т.п.), где есть крутые специалисты, которые реально знают, что и зачем делают, а не гонятся за мини-оптимизациями. На плюсах потолок скорости исполнения кода — выше, чем на шарпе. Но этот потолок нужен в лучшем случае 1% приложений. И цена этого потолка — раз 10 больше, чем цена управляемого кода на 20-30% медленнее. И потолок недостижим для большинства компаний, где все — середнячки или продвинутые середнячки.
Поэтому, если вы занимаетесь разработкой в областях, где скорость нужна, и делаете это качественно — я вас уважаю. Если вы пишете на плюсах бизнес-приложения и прочий ширпотреб, где 90% процессорного времени отнимает GUI — то выбор плюсов ошибочен.
Согласен с Вами, и в этом контексте не могу не дополнить напоминанием про замечательный перевод Насколько плохим код должен быть?
Пожалуй, хабраюзер Athari исчерпывающе ответил на Ваш комментарий.
Я лишь хочу спросить: а Вы можете назвать какое-нибудь известное .NET приложение, у которого явно выражены приведенные Вами проблемы?
Я лишь хочу спросить: а Вы можете назвать какое-нибудь известное .NET приложение, у которого явно выражены приведенные Вами проблемы?
Одного не понял — Хабр вроде как русскоязычный ресурс? А почему тогда описания NET'ов на английском? :)
Если я начну переводить на русский, меня никто не поймёт. :) Переводы многих вещей неустовшиеся. Список официальных переводов терминов отсутствует. Справка переведена автоматически, а не людьми, и переводы многих терминов выбраны совершенно от балды, и не соответствуют изначальному смыслу. Ну и я сам никогда не пользуюсь русской документацией, только когда-то очень давно читал переведённые книжки.
В общем и целом, программирование на .NET, как и всё программирование, чуть менее, чем полностью английское. Если кто-то пользовался фичей, то он знает английское название. Если не пользовался, то русское название не поможет. :)
В общем и целом, программирование на .NET, как и всё программирование, чуть менее, чем полностью английское. Если кто-то пользовался фичей, то он знает английское название. Если не пользовался, то русское название не поможет. :)
А что там переводить то?
это не описания. это теги.
Всегда последнюю (что не мешает некоторым проектам компилироваться в более старые при желании, что стало актуально с появлением версии 4.5, не поддерживающей XP). Эксперименты по переходу на новую версию начинаем когда выходит соответствующий релиз Visual Studio.
Async/await пользуетесь? Я вот совсем недавно обнаружил, что .NET 4.5 на XP не ставится (этот топик не в последнюю очередь из-за этого сюрприза возник). Есть какой-то «Microsoft.Bcl.Async», но как без переводвыподвертов собирать две версии — шут знает.
Еще есть Async CTP (полное название не помню), это реализация async/await под .NET 4.0
А если его декомпилировать, то можно и под 2.0 аналог написать, никаких принципиальных сложностей нет (у меня этот велосипед даже где-то в папке с проектами лежит)
А если его декомпилировать, то можно и под 2.0 аналог написать, никаких принципиальных сложностей нет (у меня этот велосипед даже где-то в папке с проектами лежит)
Async/await пользуетесь?
Нет. Думал попользоваться, но потом обнаружил, что внутри async обязательно должен быть другой await и, следовательно, просто выполнить параллельно свой собственный алгоритм через это дело не получится, так что продолжаем по старинке. Но, да, есть, конечно, места где async/await таки пригодится, но это не во всех проектах, в некоторых оно не нужно или нужно не на столько, чтобы ради этого отказываться от поддержки XP.
Я вот совсем недавно обнаружил, что .NET 4.5 на XP не ставится
Я это обнаружил когда решил поставить VS2012 ради последней версии ASP.Net. Пришлось поставить семёрку из-за этого.
У нас версия четко привязана к Unity3D. Они поменяли, и мы поменяли.
Мое мнение, что если, что то и писать на Net то только 2.0 и выше. В остальном и без Net писалось и работало.
Помню переход был кошмарен, и только VS2005 с ее Net 2.0 стала более адекватной… и то не без греха…
Сейчас использую Net 2 только в проектах где ну оооочень велика вероятность что не обновляли XP. В остальном 3.5 и выше.
Помню переход был кошмарен, и только VS2005 с ее Net 2.0 стала более адекватной… и то не без греха…
Сейчас использую Net 2 только в проектах где ну оооочень велика вероятность что не обновляли XP. В остальном 3.5 и выше.
Сейчас использую Net 2 только в проектах где ну оооочень велика вероятность что не обновляли XP
Когда появлялись первые версии .Net, местами ещё дискетами пользовались, доступ в Интернет был еле-еле диалап и винчи часто бывали на несколько гигов. Тогда такими вопросами задаваться было логично. Но нынче ориентироваться на то, что кто-то не может скачать SP3 и .Net 4.0 по-моему излишне, в конце концов или можно приложить их на диске если целевая аудитория — жители лесов и полей, где нет нормальной связи. Так что по большому счёту я вижу смысл в поддержке только 4.0 для XP, 2.0-3.5 по-моему можно уже дать упокоиться с миром.
В корпаративе старье… 3.5 и то доставлять… да что говорить Win2008 галку в компонентах…
Но 2 это стейт далее 3.5 стейт… потом 4 или 4.5, могу ошибаться.
Но 2 это стейт далее 3.5 стейт… потом 4 или 4.5, могу ошибаться.
Вот так и получаются программы размеров в 10 килобайт, тянущие многомегабайтную .NET 3.5 в зависимостях…
Я тоже так относился к дотнету десять лет назад. :) Но давайте будем реалистами:
1) Дотнет можно скачать. 40-50 метров (столько весят 4.x) на 256 кбпс скачаются за полчаса. Ближе к цивилизации скорость от 10 мбпс, это 1 минута.
1а) Дотнет можно приложить к инсталлятору, чтобы не мучать юзеров.
2) Дотнет можно приложить к диску (почём они нынче? 5 руб?), если диалап или полный оффлайн.
3) Дотнет ставится с обновлениями системы. Если человек не самоубийца, то обновления не отключает. Обновления (почти) идеально работают даже на пиратской винде.
Есть, конечно, корпоративные клиенты, застрявшие в прошлом. Но они — вообще проблема для программистов (и не только для них), и дотнет там явно не основная трудность. Если нервы дОроги, с ними можно просто не работать.
1) Дотнет можно скачать. 40-50 метров (столько весят 4.x) на 256 кбпс скачаются за полчаса. Ближе к цивилизации скорость от 10 мбпс, это 1 минута.
1а) Дотнет можно приложить к инсталлятору, чтобы не мучать юзеров.
2) Дотнет можно приложить к диску (почём они нынче? 5 руб?), если диалап или полный оффлайн.
3) Дотнет ставится с обновлениями системы. Если человек не самоубийца, то обновления не отключает. Обновления (почти) идеально работают даже на пиратской винде.
Есть, конечно, корпоративные клиенты, застрявшие в прошлом. Но они — вообще проблема для программистов (и не только для них), и дотнет там явно не основная трудность. Если нервы дОроги, с ними можно просто не работать.
Обычно .NET уже давно стоит на машинах. Приходит с обновлениями для винды, в версиях выше XP вообще встроен при установке.
Вот так и получаются программы размеров в 10 килобайт, тянущие многомегабайтную .NET 3.5 в зависимостях…
А как Вы относитесь к тому, что большинство программ в 10 килобайт «тянут в зависимостях» многогигабайтную Windows или Linux? :-)
Перешел на последний дотнет ради MVC4. Заодно в команде прочистили все девелоперские машины, поменяли ОС на Win7 (требование VS2012). Два дня хаоса, зато потом счастье.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
.NET Framework: Какую версию вы используете?