LINUX.ORG.RU

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

 ,


0

0

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

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

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

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

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

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

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

Это давало просто бесконечное количество вирусов. Помнится, в одной лаборатории onehalf зашифровал диски компьютеров (один полностью), так все аспиранты и доценты ощутили себя гибкими и эластичными. И, да, onehalf был полиморфным стелсом https://ru.wikipedia.org/wiki/OneHalf

anonymous
()

С потерей гибкости, связанной с возможностью модификации кода во время исполнения,

ты бы почитал https://ru.wikipedia.org/wiki/Рефлексия_(программирование)

разработчики стали искать другие источники гибкости, с переменным успехом пытаясь получить её в ООП, ФП, АОП и т.д.

про «гибкость», ты серьёзно?

Но было очевидно, что всё это не то.

да, да, да... «фатальный недостаток»!

anonymous
()

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

..с безопасным доступом к какому коду? к «машинному» коду? JVM?

Кто не слышал о реализации корутин для Java модификацией байт-кода?

судя по всему, не слышал ты, почитай: https://ru.wikipedia.org/wiki/Сопрограмма

«Применение сопрограмм являлось методикой ещё ассемблера, практиковалось лишь в некоторых высокоуровневых языках (Simula, Modula-2). Сопрограммы хорошо пригодны для реализации многих похожих компонентов программ (итераторов, бесконечных списков, каналов, совместных задач).»

...и при чём тут модификация байт-кода?

anonymous
()

JVM была недостаточно хороша, поэтому знамя подхватил .NET.

ну, да, за извращённую реализацию java получили в пятак, и давай искать, какое бы знамя подхватить

anonymous
()

Зачем нужен кривой и зональный NET, когда есть Dis?
P. S. Забыл переключить раскладку и сначала вместо «Dis» написал «Вшы»

awesomebuntu
()

Чем он хуже жабы? А вообще, это хреновины, права на которые держат жадные проприерасы.

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

Если серверную JVM (для 64-битных ОС) сменить на клиентскую (ту, что обычно используется в 32-битных ОС), то долгого «разогрева» не будет - байткод будет JIT'ится по мере выполнения. На 64-битную ОС Oracle разрешает ставить как 64-битную, так и 32-битную JRE.

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

Проблема в том, что другие IDE грузятся ещё дольше.

EXL ★★★★★
()

JVM была недостаточно хороша

Ору.

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

Как была достаточно производительной IDE, так и осталась

Раньше намного быстрее стартовала

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

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

Потому что хотели One Ring to rule them all.

no-such-file ★★★★★
()
Ответ на: комментарий от SjZ

а его новая версия на «старые» ОС (по аналогии с Win7) вообще не встанет

Кстати у меня от этого сильно пригорело однажды. С тех пор ненавижу Apple и всё что с ней связано.

no-such-file ★★★★★
()
Ответ на: комментарий от mbivanyuk

Я бы например не стал размахивать индусокодерством. Чтобы так затормозить дотнет, да на чистой арифметике, надо писать не приходя в сознание и не имея понятия как он работает.

Хотя хз что ты там хотел доказать. Производительность != быстрые_числодробилки, они пишутся на других языках и неплохо цепляются к дотнету. Ясен пень что шарп - не фортран, и надо упороться чтоб их сравнивать.

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

Ясен пень что шарп - не фортран, и надо упороться чтоб их сравнивать.

числодробилки вычисляются на ссах с фортранами на 5% быстрее, иногда наоборот медленнее. так что нативность по любому сосет. для неучей повторю, у .NET единственный недостаток это недетерменированная сборка мусора, блокирующая все потоки. а гуйки и на залупокрестах тормозят, к тому же тормозят больше, ибо память выделяют стандартным тормознутым new.

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

Visual Studio переписали на C#

Щаз. devenv как была 32-х битным нативным процессом так и осталась.

Открываем один проект (Quake 2) в CLion

Ну и зачем эту недоподелку тут обсуждать? QtCreator и Eclipse ты не рассматриваешь, да? :)

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

Согласен - глючность и тормознутость этого так называемого IDE хорошо показывает всю суть MS :D

У меня QtCreator неделями живет в системе на работе, а студия у людей раз в день обычно вылетает.

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

Щаз. devenv как была 32-х битным нативным процессом так и осталась.

херб задтер перпейсал студию на C++ 14x? неудивительно, что она стала еще более тормознутой. а шарпдевелоп на том же проекте работает шустро.

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

Ты просто с C++ не знаком.

Это я с .NET почти не знаком, только читал статьи, где всякие классные штуки делают с помощью Reflection.Emit.

А вот с C++ я как раз очень знаком, да.

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

Ну, например, Visual Studio переписали на C#

И стала эта студия лютой тормозной фекалью :( с 10 версии пользоваться ей нереально. Даже сrаный эклипс с кривой во все стороны CDT шустрее шевелится.

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

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

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

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

Зачем?

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

Скорее не на «похожий язык», а на нативный C#. На C++ABI натянуть .NET фреймворк, мне кажется, не получится. Ну или получится, но будет монстор уровня gobject или даже лучше

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

В сравнении с Java-поделками от JetBrains, MSVS значительно выигрывает как быстродействием, так и жором RAM.

Некоторое время назад я всерьез раздумывал перейти на Ксамарин вместо написания нативных андроид-приложений. Имею вам сказать, что главная причина моего отказа от - это то, что вижал студия на винде (8 на тот момент) работала в разы хуже, нежели intellij idea на линупсе на том же самом железе.

Но да, можете верить в свою сказочку и дальше кушать это поделие.

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

а у Вас не осталось того кода? Я бы был рад такое погонять сам и побенчить.

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

Некоторое время назад я всерьез раздумывал перейти на Ксамарин вместо написания нативных андроид-приложений

С какой целью? Кроссплатформа или C#?

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

где всякие классные штуки делают с помощью Reflection.Emit

Я не поклонник рефлексии где можно легко обойтись без неё. Честно говоря она (в явном виде) мне нужна довольно редко.

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

OLE появилось позже COM, и собственно является технологией встраивания UI-компонентов друг в друга на основе COM. А так, смешно.

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

Лол, SO-man'а уважаю по С++ тредам, но пожалуйста не комментируйте больше про JVM - не позорьтесь. .NET VM - это такая легковесная (читай недоделанная) JVM, которая по ряду причин генерит код значительно хуже чем HotSpot. Про AOT в Java - man jaotc. GCJ закопали, потому-что все разработчики с него перехали на OpenJDK 10 лет назад.

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

Вообще-то там два варианта GC, и оба инкрементальные емнип

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

Вообще-то есть C++/CLI который умеет и .NET и C++ ABI и сишное(как просто extern C, так и уровня COM), и при этом поддерживает последние стандарты плюсов

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

System.Reflection.Emit это не рефлекшн, в прямом смысле этого слова, а инструмент генерации байткода вообще-то. Можно прямо в рантайме его генерировать и потом сохранять или запускать.

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

.NET VM на порядок более продвинутая, чем JVM, но тут надо сказать все дело просто в обратной совместимости. Типа там, tailcall. Вот когда ее в жвм введут, тогда и приходите.

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

Про AOT в Java - man jaotc.

http://openjdk.java.net/jeps/295

JEP 295: Ahead-of-Time Compilation

Owner Vladimir Kozlov
Created 2016/09/15 01:20
Updated 2017/03/07 11:58
...
Description

AOT compilation of any JDK modules, classes, or of user code, is experimental and not supported in JDK 9.

С каких пор в .NET-е есть ngen сами нагуглите?

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

Такая поделкак как VS может тормозить даже при вырезании строки, у неё видете ли идёт форматирование кода. А ты тут про качество говоришь.

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

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

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

Хороший вопрос. Пока студия не прогреется работать не комфортно. А вот после прогрева она почти не тормозит. И как она почти не тормозит в не очень виртуалке, так тормозит и на относительно быстром ноутбуке.

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

Для тех кто создаёт на нём программы, очевидно же. В отличии от всяких шарпов собирается во вполне себе нативный код. И в отличии от новомодных rust, go имеет вполне себе достаточно выразительных средств для ооп.

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

А во что собирается си? В код для виртуальной машины? При чём тут устаревшие биндинги? И вообще, с чего ты взял что они устаревшие?

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

GCJ закопали, потому-что все разработчики с него перехали на OpenJDK 10 лет назад.

Странно, gcc-ecj-4.5 недавно собрал вместе с gcc5-devel-5.4.1.s20170425.

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