LINUX.ORG.RU

Почему .NET лучше натива, моё мнение

 ,


0

0

Надеюсь, тут сидят не одни школьники, а есть и люди, которые наверняка помнят, как было весело во времена DOS и реального режима, когда возможно было писать на ассемблере самомодифицирующийся код. Это давало просто бесконечную гибкость.

С выходом на сцену так называемых языков высокого уровня стало немодным привязываться к платформе (хотя 99% crapware так и не осилили перенести с wintel32 даже на wintel64) или модифицировать двоичный код во время исполнения. От последнего даже появились защиты.

С потерей гибкости, связанной с возможностью модификации кода во время исполнения, разработчики стали искать другие источники гибкости, с переменным успехом пытаясь получить её в ООП, ФП, АОП и т.д. Но было очевидно, что всё это не то.

Все изменилось с появлением JVM: появилась единая платформа с безопасным доступом к «машинному» коду. Кто не слышал о реализации корутин для Java модификацией байт-кода?

JVM была недостаточно хороша, поэтому знамя подхватил .NET. Хотите, например, AOP со связыванием/отвязыванием концептов во время исполнения без модификации исходников? Есть и такое. Хотите генерировать код в рантайме? Запросто. JIT оптимизирует до маш. кода, производительность не пострадает.

.NET принёс нам бесконечную гибкость плюс типобезопасность. Наверное поэтому его так любит Луговский, за простоту компиляции DSL-ей.

Ответ на: комментарий от Twissel

Причём разбирательство касалось неаутентичного визуального интерфейса и средств межпроцессного взаимодействия. Microsoft раньше Sun предложила Java Foundation Classes и COM-интерфейсы-обёртки для JavaBeans, чтобы их можно было использовать в VisualStudia/VisualC++/VisualBasic. А у Sun к тому времени готовилась библиотека Swing и был уже RMI, шитые «белыми нитками». Ну не успевали они выпустить релиз очередной JRE с этими библиотеками! Вот и началась судебная заварушка о том, почему это Microsoft привязала ключевые технологии Java к своей операционной системе, не согласовав это с Sun.

iZEN ★★★★★
()
Ответ на: комментарий от iZEN

А мне казалось что там дело было в несовместимых реализациях. Что МС положила болт на стандарт и при этом выпустила свою собственную незалежную JVM, которая поломала сановскую пиар-мантру write once run everywhere. И за это сан их и засудил: за использование бренда Java когда по сути совместимости не было.

morse ★★★★★
()
Ответ на: комментарий от morse

В общем-то да - MS «расширила» функциональность JVM и погубила переносимость Java, как считали в Sun.

iZEN ★★★★★
()

.NET принёс нам бесконечную гибкость плюс типобезопасность.

Не знаю кому «вам», а «нам» .NET принес только очень много геморроя с mono и жирные десктоп-прилады которым он вообще нахрен был не нужен (за что мы все бесконечно благодарны Мигелюшке).

morse ★★★★★
()

По производительности всегда так радужно всё у шарпа? Вот прям всегда оптимизирует? Как там в сравнении с Си/плюсами/фортраном?

zamazan4ik ★★
()
Ответ на: комментарий от anon_2018

Очевидно, что в приложениях уровня laba1.exe всю мощь .NET не прочувствуешь.

Ага, значит уже начинают появляться особые условия, значит уже .NET далеко не всегда лучше натива, так видимо?

видимо имеет смысл тему переименовать

Почему .NET лучше натива в определенных специфических ситуациях

morse ★★★★★
()
Ответ на: комментарий от zamazan4ik

Ну, например, Visual Studio переписали на C#. Как была достаточно производительной IDE, так и осталась. В сравнении с Java-поделками от JetBrains, MSVS значительно выигрывает как быстродействием, так и жором RAM.

Шутка ли, солюшены трёх игр: Quake 2, Quake 3, Doom 3 открытых в MSVS и жор памяти всего 1.5 ГБ.

Открываем один проект (Quake 2) в CLion, вуаля — 6 ГБ съело сразу, все четыре ядра по 99.9%, куллера завизжали как сучки и началась 5-минутная индексация на SSD (sic!).

Качество продуктов на лицо. Всё-таки Visual Studio — лицо MS.

EXL ★★★★★
()
Ответ на: комментарий от morse

Ага, значит уже начинают появляться особые условия, значит уже .NET далеко не всегда лучше натива, так видимо?

Ты ОП-пост не читал? Или ничего в нём не понял?

anon_2018
() автор топика

Cамомодификация никуда не делась, VirtualProtect или как её там mprotect и меняй что хошь. Другое дело сложность и объем основного кода такой что ничего делать с ним не хочется.

ilovewindows ★★★★★
()
Ответ на: комментарий от EXL

Я просил сравнение с тем, что я написал:) про джавку я и так знаю.

zamazan4ik ★★
()
Ответ на: комментарий от anon_2018

Очень хорошо понял. Я бы его правда озаглавил не «почему .NET так неимоверно крут», а «краткая история технологий программирования от человека который в этих самых технологиях не разбирается».

morse ★★★★★
()
Ответ на: комментарий от zamazan4ik

Надо будет попробовать на работе. Если не забуду, отпишусь.

EXL ★★★★★
()
Ответ на: комментарий от EXL

Всё-таки Visual Studio — лицо MS.

Но поставить MSVS CE с iso-шника для оффлайн установки (2013, 2015, 2015-3) В Win7 лучше не пытаться - для оффлайн установки потребуется подключение к интернету, так как ему захочется проверить сертификаты на «пакеты» из состава установщика. То есть просто наличия установленного SP1

grem ★★★★★
()

.NET принёс нам бесконечную гибкость плюс типобезопасность

.. потом 90-е закончились, пришел LLVM, компании стали возвращаться к компилируемым языкам. Go, Rust, Swift. Даже у майкрософт подгорело от скорости работы их поделия и API для плиток они уже сделали не на #, а на ++

makoven ★★★★★
()
Последнее исправление: makoven (всего исправлений: 2)
Ответ на: комментарий от EXL

Шутка ли, солюшены трёх игр: Quake 2, Quake 3, Doom 3 открытых в MSVS и жор памяти всего 1.5 ГБ.

А ты думаешь там модель кода тоже на до-диезе писана? ЕМНИП, у них в IDE использовалась та же реализация С++-парсера, что и в cl.exe, думаю что так и осталось

annulen ★★★★★
()
Ответ на: комментарий от RazrFalcon

Ну про 90-е это для красного словца)

Мне другое интересно. Ночему майкрософт выбрали путь с виртуальной машиной. Ведь проблема была, по сути, лишь в том, что сишное ABI умеет экспортировать только функции. Могли бы просто запилить рядом новое ABI для компилируемого кода, с классами и другими плюхами. Выпустили бы открытую спеку. Там, глядишь бы и линукс с эплом подтянулись. И все счастливы и фреймворк таскать не надо

makoven ★★★★★
()
Последнее исправление: makoven (всего исправлений: 1)
Ответ на: комментарий от makoven

Там, глядишь бы и линукс с эплом подтянулись

На самом деле, все наборот получилось: у линукса, эппла и всех остальных есть универсальный ABI для С++, а МС только в VS 2017 наконец-то первый раз не сломала совместимость с предыдущей версией

annulen ★★★★★
()
Ответ на: комментарий от annulen

Но сломала всё остальное =) Теперь rust не работает с 2017, но прекрасно работает со старой версией.

RazrFalcon ★★★★★
()

Скучный вброс. .NET пользуется кучка виндузятников в кружке по интересам. Вот пусть и дальше там сидят. А нам этого ненужно.

th3m3 ★★★★★
()
Ответ на: комментарий от grem

Это ничего, Xcode еще и не такое спрашивает, а его новая версия на «старые» ОС (по аналогии с Win7) вообще не встанет.

SjZ ★★★★★
()
Ответ на: комментарий от annulen

универсальный ABI для С++

Так он не новый, а обычный сишный, с уродованием названий функций. Фич маловато, чтоб зваться универсальным. На таком обрубке врятли можно построить развесистое дерево классов delphi .NET.

makoven ★★★★★
()
Ответ на: комментарий от makoven

Мне другое интересно. Ночему майкрософт выбрали путь с виртуальной машиной.

Э... Вы про что? В .NET-е компиляция идет в промежуточное представление MSIL, которое _перед_ исполнением транслируется в нативный код (т.е. в .NET-е AOT-компиляция). Более того, в .NET-е есть ngen, который позволяет преобразовать .NET-приложение в нативное представление целиком.

А виртуальная машина — это как раз Java и JVM. Там как раз JIT (т.е. сперва собирается статистика работы VM, затем самые «горячие» куски транслируются в нативный код). Из-за чего Java показывает приличную производительность только на server-side, где есть возможность «прогреть» VM. Проект GСС пытался сделать AOT для Java и это в какой-то степени получилось, но результат был настолько так себе, что в итоге GCJ закопали.

eao197 ★★★★★
()
Ответ на: комментарий от anonymous

Ну так в VS 2015 появился universal CRT. У линукса подобного просто нет, несмотря на ABI.

И на кой он в линуксе нужен?

annulen ★★★★★
()

говно этот ваш .нет

C# может и нормальный, а вот .нет полная микрософтовская параша

и разрабы, которые делают привязку к .нет платформе ушлёпки

1) Людей, которые повышают минимальную необходимую версию .нет без явной на то причины за программистов или разработчиков не считаю. Они для меня на уровне веб-макак. 2) Даже если прога никаких новых фич из очередной новой версии не требует (т.е. «новизна» состояла в обновлении чего-то внутри самого .нет-а), без доступа и вмешательства в исходники успешный запуск мало кому светит. 3) Установить версии .нет начиная с 4.N (жаль, я не помню что за N) на windows 8.1, у которой заморожены апдейты (а некоторые апдейты удалены тулзой «destroy windows 10 spying») невозможно - инсталлятор новой версии .нет-а банально требует некоторые «KB» обновления. Которые я, естественно, ставить не собираюсь.

anonymous
()

http://i72.narod.ru/humor/revolution.htm

История программных революций от Microsoft, вкратце:

Сначала были Windows API и DLL Hell. Революцией N1 было DDE - помните, как ссылки позволили нам создавать статусные строки, отражающие текущую цену акций Microsoft? Примерно тогда же Microsoft создала ресурс VERSION INFO, исключающий DLL Hell. Но другая группа в Microsoft нашла в DDE фатальный недостаток - его писали не они!

Для решения этой проблемы они создали OLE (похожее на DDE, но другое), и я наивно вспоминаю докладчика на Microsoft-овской конференции, говорящего, что скоро Windows API перепишут как OLE API, и каждый элемент на экране будет ОСХ-ом. В OLE появились интерфейсы, исключающие DLL Hell. Помните болезнь с названием <по месту>, при которой мы мечтали встроить все свои приложения в один (возможно, очень большой) документ Word? Где-то в то же время Microsoft уверовала в религию С++, возникла MFC решившая все наши проблемы еще раз.

Но OLE не собиралась, сложа руки смотреть на это, поэтому оно заново родилось под именем COM, и мы внезапно поняли, что OLE (или это было DDE?) будет всегда - и даже включает тщательно разработанную систему версий компонентов, исключающую DLL Hell. В это время группа отступников внутри Microsoft обнаружила в MFC фатальный недостаток - его писали не они! Они немедленно исправили этот недочет, создав ATL, который как MFC, но другой, и попытались спрятать все замечательные вещи, которым так упорно старалась обучить нас группа COM. Это заставило группу COM (или это было OLE?) переименоваться в ActiveX и выпустить около тонны новых интерфейсов (включая интерфейсы контроля версий, исключающие DLL Hell), а заодно возможность сделать весь код загружаемым через броузеры, прямо вместе с определяемыми пользователем вирусами (назло этим гадам из ATL!).

anonymous
()
Ответ на: комментарий от anonymous

http://i72.narod.ru/humor/revolution.htm

Группа операционных систем громким криком, как забытый средний ребенок, потребовала внимания, сказав, что нам следует готовиться к Cairo, некой таинственной хреновине, которую никогда не могли даже толком описать, не то, что выпустить. К их чести, следует сказать, что они не представляли концепции <System File Protection>, исключающей DLL Hell. Но тут некая группа в Microsoft нашла фатальный недостаток в Java - её писали не они! Это было исправлено созданием то ли J, то ли Jole, а может, и ActiveJ (если честно, я просто не помню), точно такого же как Java, но другого. Это было круто, но Sun засудило Microsoft по какому-то дряхлому закону. Это была явная попытка задушить право Microsoft выпускать такие же продукты, как у других, но другие.

Помните менеджера по J/Jole/ActiveJ, стучащего по столу туфлей и говорящего, что Microsoft никогда не бросит этот продукт? Глупец! Все это означало только одно - недостаток внимания к группе ActiveX (или это был COM?). Эта невероятно жизнерадостная толпа вернулась с COM+ и MTS наперевес (может, это стоило назвать ActiveX+?). Непонятно почему к MTS не приставили <COM> или <Active> или <X> или <+> - они меня просто потрясли этим! Они также грозились добавить + ко всем модным тогда выражениям. Примерно тогда же кое-кто начал вопить про <Windows DNA> (почему не DINA) и <Windows Washboard>, и вопил некоторое время, но все это почило раньше, чем все поняли, что это было.

К этому моменту Microsoft уже несколько лет с нарастающей тревогой наблюдала за интернет. Недавно они пришли к пониманию, что у Интернет есть фатальный недостаток: ну, вы поняли. И это приводит нас к текущему моменту и технологии .NET (произносится как <doughnut (пончик по-нашему)>, но по-другому), похожей на Интернет, но с большим количеством пресс-релизов. Главное, что нужно очень четко понимать - .NET исключает DLL Hell.

В .NET входит новый язык, C#, (выясняется, что в Active++ Jspresso был фатальный недостаток, от которого он и помер). .NET включает виртуальную машину, которую будут использовать все языки (видимо, из-за фатальных недостатков в процессорах Интел). .NET включает единую систему защиты (есть все-таки фатальный недостаток в хранении паролей не на серверах Microsoft). Реально проще перечислить вещи, которых .NET не включает. .NET наверняка революционно изменит Windows-программирование... примерно на год.

anonymous
()
Ответ на: комментарий от makoven

C++ ABI это не только названия функций.

anonymous
()
Ответ на: комментарий от anon_2018

Ты ОП-пост не читал? Или ничего в нём не понял?

здаётся нам, мил члвек, что ты сильно ценишь свой рекламный высер.

anonymous
()
Ответ на: комментарий от anon_2018

Создай свою тему и озаглавливай как хочешь.

так ты, мил члвек, сюда не поговорить пришёл, а рекламку свою продвинуть?

anonymous
()

Серьёзная модификация программы во время исполнения делает её труднопонимаемым говном. /thread

ЗЫ

Пишу на C#. Любят его как раз за простоту (по сравнению с C++). Перед жабой выигрывает на Windows тем, что программы на C# в оффтопике запускаются мгновенно, по сравнению с медленным разогревом здорового Java рантайма. А после запуска работают примерно одинаково быстро.

peregrine ★★★★★
()
Ответ на: комментарий от morse

принес только очень много геморроя с mono

Какого?

жирные десктоп-прилады которым он вообще нахрен был не нужен

Вот vala не нужен, это да.

peregrine ★★★★★
()
Ответ на: комментарий от zamazan4ik

По производительности всегда так радужно всё у шарпа? Вот прям всегда оптимизирует? Как там в сравнении с Си/плюсами/фортраном?

Году в 2010 пробовал я один и тот же алгоритм на C# и С++ (в VS, чистая арифметика и никакого GUI и прочего) по времени выполнения. То что на С++ просчитывалось за доли секнуды на С# можно было успеть неторопясь чайку попить, а если размерность данных велика то и вздремнуть еще часок. С тех пор когда вижу в одном контексте «С#» и «производительность» мне смешно, сомневающимся могу посоветовать провести подобное тестирование самомстоятельно. Видать не зря несмотря на все усилия MS этим никто не пользуется в отличие от Java например.

mbivanyuk ★★★★★
()

Удивительно, но я согласен с клоном anonimous. Хотя подобные фишки не только .net позволяет.

hateyoufeel ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.