10

А точнее, зачем их вообще используют и зачем (в каких ситуациях) лучше их использовать? Вот посудите сами.
Managed languages:

  1. Выполняются в виртуальной машине (соответственно, требуют больше инструкций для выполнения инструкций языка)
  2. Являются интерпретируемыми (выходит из первого пункта), соответственно, требуют больше памяти\ресурсов машины, а значит, программы написанные с их использованием работают медленнее, требуют больше ресурсов, вычислений, и т.п.

В то время как программы, написанные (скомпилированные прямо в машинный код) на "обычных" процедурных\объектно-ориентированных языках, вроде того же С или С++, обладают куда большей скоростью, производительностью, куда менее требовательны к памяти и ресурсам системы.

И почему, к примеру, если я хочу использовать в своей программе систему классов NET Framework, я обязан перейти на виртуальную машину? Что, если я хочу, чтобы мой код компилировался в машинный?

Например, мой одногрупник решил писать на Java, мотивируя свой переход с плюсов на яву тем, что в C++, якобы, нужно иметь дело со "всеми этими указателями" (и он даже ничего не слышал ни про RAII, ни про smart ptr'ы), а в Jave, вот, есть GarbageCollector, и ни о чем думать и заботиться не надо.

В чем же причина такого массового распространения managed языков, какую нишу они занимают, и какая судьба в будущем ждет языки вроде С,C++, Haskell, и т.д.?

9
  • 3
    > В худшем случае про него могут только забыть. Чем не смерть? =) 7 окт 2012 в 19:40
  • 8
    > Также он не будет писать компьютерную игру на C#. Весьма спорно. Чем C# помешает написать компьютерную игру (именно игру, а не граф. движок)? Managed-языки куда приятнее для описания иерархии игровых объектов и игровой механики.
    – Nofate
    8 окт 2012 в 6:05
  • 6
    Также он не будет писать компьютерную игру на C#. лолшто? На шарпе очень даже можно писать игры, вполне себе быстрые и красивые
    – nolka
    8 окт 2012 в 6:11
  • 5
    - Сам вопрос какой-то мутный. Почему в таком случае не спросить, например, как писать сайты на машинном коде. Javascript под V8 же выполняется на виртуальной машине, а я, скажем, хочу, чтобы мой сайт компилировался в машинный код. - Все managed языки решают определенный спектр задач. И разговор о выборе языка / платформы / компилятора / дополнительных тулз имеет смысл только тогда, когда точно сформулирована задача. А так разговор неконструктивен - ну да, IL, GC, JIT. Ну да, в C++ не так. - Никто, кстати, не упомянул про NGEN. 8 окт 2012 в 13:05
  • 3
    Почему-то все начинающие программисты зацикливаются на скорости. Хотя ПРАКТИКА показывает, что, к примеру, довольно нагруженные сайты успешно функционируют на сравнительно медленных Python и Ruby. В работе реальной системы значительная часть производительности зависит не от языка, а, к примеру, от базы данных. Но, если уж Вас так смущает скорость, то посмотрите на Хаскель и Го - они компилируются, виртуальных машин не держат, однако управление памятью присутствует.
    – Softa
    22 сен 2013 в 9:25

4 ответа 4

16

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

В то время как программы, написанные (скомпилированные прямо в машинный код) на "обычных" процедурных\объектно-ориентированных языках, вроде того же С или С++, обладают куда большей скоростью, производительностью, куда менее требовательны к памяти и ресурсам системы.

Это спорно.

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

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

И почему, к примеру, если я хочу использовать в своей программе систему классов NET Framework, я обязан перейти на виртуальную машину? Что, если я хочу, чтобы мой код компилировался в машинный?

Тогда вам наверное не по пути.

Например, мой одногрупник решил писать на Java, мотивируя свой переход с плюсов на яву тем, что в C++, якобы, нужно иметь дело со "всеми этими указателями" (и он даже ничего не слышал ни про RAII, ни про smart ptr'ы), а в Jave, вот, есть GarbageCollector, и ни о чем думать и заботиться не надо.

У вашего одногруппника очень здравая позиция, он выбирает функционал и избегает лишней сложности. Это ведь великолепно, что GC снимает часть головной боли с программиста. А то что повышается потребление ресурсов, то это имеет значение лишь в том случае, если ощутимо заметно для пользователя. В остальных случаях -- это серьёзная оптимизация времени программиста.

В чем же причина такого массового распространения managed языков,

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

какую нишу они занимают, и какая судьба в будущем ждет языки вроде С,C++, Haskell, и т.д.?

Си похоже не умрёт никогда. Haskell, как жертва постоянных экспериментов и исследований -- тоже. Зато C++ очень даже может сдохнуть, ибо слишком сложен, и преимущества не стоят недостатков.

UPD: Нашёл очень занятную дискуссию. Внезапно обнаружилось что реализация языка Lua, LuaJIT выполняется быстрее чем код на языке D. При том, что язык D -- статически типизированный, компилируется в нативный код, тогда как Lua -- динамически типизированный, с JIT-компиляцией. Такие дела.

10
  • 1
    Извините, а как долго Вы писали на C++?
    – stremm
    7 окт 2012 в 20:16
  • 7
    недолго, где-то полгода. Потом я познакомился огромным количеством других, проработанных, изящных и гибких языков программирования, и считаю что имею право судить. 7 окт 2012 в 20:57
  • 5
    "Не писал, но осуждаю"
    – Dith
    8 окт 2012 в 4:27
  • 1
    Пускай на С++ пишут драйвера или пусть какие еще спецы работают, но не всем же писать эту фигню
    – semenvx27
    14 июн 2013 в 21:59
  • 1
    @z668: Судя по всему, альтернатива представляется не в плюсах, а плюсам: это C#. Он, кстати, в последнее время быстро развивается, один только async/await уже впереди планеты всей.
    – VladD
    20 окт 2014 в 21:43
9

Выигрыш от использования managed languages, лучше всего виден на простом примере с J2ME (Java Mobile):

Вот представьте, вы разработчик проги для мобильного телефона. Количество ОС для мобильных устройств - ну хорошо если меньше 100. По факту у каждого производителя телефонов их штук по 5 по 6. Популярных осей для мобильных телефонов что-то порядка 20-ти. Итого, что я должен делать как разработчик? Фактически взять и написать прогу для десятка различных осей. При этом вынесем за скобку, что документации половину этих осей практически нет. За примером далеко ходить не будем и возьмем например Nokia OS, на котором работает 90% телефончиков (не смарфонов) Nokia. В общем это ночной кошмар разработчика.

В случае же managed language - в данном конкретное примере Java ME - все решается просто и изящно: вы все знаете как.

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

2
  • Правда, относится ли J2ME в свете этого опроделения к managed languages большой вопрос.
    – avp
    8 окт 2012 в 12:54
  • Ну это всего лишь определение Microsoft, но мы то понимаем, что Java относится к managed - по крайней мере топистартёр, Java тоже имел ввиду
    – Barmaley
    8 окт 2012 в 13:01
8

В попытке ответить на вопрос, можно сказать следующее: Специфические средства управления сложностью управляемых и интерпретируемых языков снимают большой процент нагрузки на программиста, как следствие удешевляют стоимость разработки и ускоряют её процесс. Эти языки не столь требовательны к квалификации и имеют низкий порог вхождения. Как следствие, имеют более узкую (по разнообразию) область применения, удовлетворяя при этом большую часть спроса на ПО. По сему и имеют больше количество адептов.

Вообще инструмент по задаче. Болты молотком не закручивают.

Расставим точки над i:

Производительность: Программы под виртуальные машины, а тем более интерпретаторы всегда будет более ресурсоемкими. Нативный код с оптимизациями под конкретную платформу выполняется быстрее Детерминированное освобождение ресурсов сильно способствует сокращению их расхода Полное отсутствие возможности низкоуровневого программирования не позволяет управлять ресурсами с максимальной эффективностью

На практике можно рассмотреть следующий список задач, где managed языки практически неприменимы:

  • lock-free алгоритм/структуру данных.
  • Вычислительный алгоритм (численные алгоритмы или динамическое программирование приветствуется)
  • ПО для встраиваемых систем
  • Драйвер ;)
  • Стек сетевых протоколов =))

А для тех, кто в танке пусть попробуют написать/найти реализацию (на дотнете или руби, например), так чтобы было быстрее нативных языков (С/С++ к примеру)

Парадигмы: Метапрограммирование: надеюсь не будет открытием Америки факт доказательства того, что шаблоны С++ являются Тьюринг-полным языком. Кардинальное отличие от шаблонов Java/C#, которые больше похожи на макроподстановки с бонусами. Что это значит? Во первых значит что мы можем сделать любое вычисление еще на стадии компиляции, таким образом сокращая работу времени выполнения. Во вторых имеем инструмент (фактически язык в языке) для кодогенерации который означает возможность введения любой парадигмы без модификации языка:

  • Лямбда функции еще старого С++03
  • Встраивание DSL
  • Контрактное программирование
  • Аспектно-ориентированное программирование
  • Type-erasure
  • Различного рода синтаксический сахар
  • Compile-time контейнеры/алгоритмы
  • etc.

Интересно было бы взглянуть, как все это будет выглядеть на том же руби, без форка или выпуска минорной версии языка

Кроссплатформенность: Кроссплатформенность зависит не от языка, а от специфики задачи.

9
  • 4
    > ПО для встраиваемых систем Однако, Java и туда проникла.
    – Nofate
    8 окт 2012 в 7:34
  • 2
    А на .NET вообще ОС есть: Cosmos (операционная система).
    – allcreater
    8 окт 2012 в 8:28
  • 3
    @Dith а чем аргументирована неприменимость managed языков для lock-free алгоритмов и структур данных (особливо на структурах-то это как отражается) и вычислительного программирования?
    – alexlz
    8 окт 2012 в 20:12
  • 2
    @Dith откуда выводы? Поскольку весьма интересные идеи многопоточности сейчас отрабатываются в haskell (не managed, но минимализмом не пахнет), то интересно, как Вы пришли к таким выводам?
    – alexlz
    9 окт 2012 в 1:39
  • 4
    > А для тех, кто в танке пусть попробуют написать/найти реализацию (на дотнете или руби, например), так чтобы было быстрее нативных языков (С/С++ к примеру) digitalmars.com/d/archives/digitalmars/D/… 15 янв 2013 в 18:01
1

Помимо всего прочего, нужно еще помнить следующее:

  1. Далеко не всем требуется более высокая скорость, предоставляемая языками, компилируемыми прямо в машинный код. Если вы пишете какое-нибудь веб-приложение, да еще и взаимодействующее с базой данных, то биться за каждый такт процессора вряд ли имеет смысл.
  2. Тот же C# неотделим от .NET с его тысячами и тысячами классов на все случаи жизни (аналогично и Java), тогда как в стандартной библиотеке С++ этого нет, что требует искать сторонние решения
  3. Тот же С++ в силу необходимости следить за памятью самостоятельно (а также более сложного и запутанного синтаксиса, большей низкоуровневости и много чего еще) является языком с более высоким порогом входа, нежели Java и C# (не говоря уж о php и javascript)
7
  • 1
    @DreamChild: а вы о JIT слыхали? C# и Java уже давно компилируются в самый что ни на есть машинный код.
    – VladD
    15 янв 2013 в 18:13
  • это каким-то образом противоречит тому, что я сказал?
    – DreamChild
    15 янв 2013 в 18:20
  • 1
    >не говоря уж о php и javascript не скажите, на js даже числа сравнивать без посторонней помощи тяжело
    – Spectre
    15 янв 2013 в 18:29
  • Насчет "искать сторонние решения для С++" - это бредовая позиция. Изначально, по цели своего создания, С++ это не мегамонстр как "система .NET". У .NET - другие цели создания. Сравнивать "стандартные" библиотеки просто глупо. Например, в мире веб-программирования никому и в голову не приходит жаловаться, что в стандартную библиотеку Python не входят веб-фреймворки - не проблема взять и использовать десятки отличных фреймворков... А в мире Java даже наоборот - не смотря на наличие "стандартных" средств существует множество альтернативных библиотек для веб-разработки.
    – Softa
    22 сен 2013 в 8:45
  • 1
    >Насчет "искать сторонние решения для С++" - это бредовая позиция почему же бредовая? Речь, о том что в C#/java прямо "из коробки" есть огромное количество всяческих средств - и работа с сетью, и с бд, и с xml и с файловой системой и много чего еще. В С++ всего этого "из коробки" нет. Это определенно является преимуществом, даже несмотря на то, что для С++ все это также можно найти в составе других библиотек - ведь в случае с вышеперечисленными языками над этим совсем не надо задумываться
    – DreamChild
    21 окт 2014 в 6:21

Ваш ответ

By clicking “Отправить ответ”, you agree to our terms of service and acknowledge you have read our privacy policy.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками или задайте свой вопрос.