А точнее, зачем их вообще используют и зачем (в каких ситуациях) лучше их использовать? Вот посудите сами. Managed languages: Выполняются в виртуальной машине (соответственно, требуют больше инструкций для выполнения инструкций языка) Являются интерпретируемыми (выходит из первого пункта), соответственно, требуют больше памяти\ресурсов машины, а значит, программы написанные с их использованием работают медленнее, требуют больше ресурсов, вычислений, и т.п. В то время как программы, написанные (скомпилированные прямо в машинный код) на "обычных" процедурных\объектно-ориентированных языках, вроде того же С или С++, обладают куда большей скоростью, производительностью, куда менее требовательны к памяти и ресурсам системы. И почему, к примеру, если я хочу использовать в своей программе систему классов NET Framework, я обязан перейти на виртуальную машину? Что, если я хочу, чтобы мой код компилировался в машинный? Например, мой одногрупник решил писать на Java, мотивируя свой переход с плюсов на яву тем, что в C++, якобы, нужно иметь дело со "всеми этими указателями" (и он даже ничего не слышал ни про RAII, ни про smart ptr'ы), а в Jave, вот, есть GarbageCollector, и ни о чем думать и заботиться не надо. В чем же причина такого массового распространения managed языков, какую нишу они занимают, и какая судьба в будущем ждет языки вроде С,C++, Haskell, и т.д.?
Ответ
Являются интерпретируемыми (выходит из первого пункта), соответственно, требуют больше памяти\ресурсов машины, а значит, программы написанные с их использованием работают медленнее, требуют больше ресурсов, вычислений, и т.п. В то время как программы, написанные (скомпилированные прямо в машинный код) на "обычных" процедурных\объектно-ориентированных языках, вроде того же С или С++, обладают куда большей скоростью, производительностью, куда менее требовательны к памяти и ресурсам системы. Это спорно. Во-первых, в современных средах используют агрессивный JIT, который может выдавать код исполняющийся быстрее чем тот что компилируется статически (ниже занятный пример такого превосходства), за счёт дополнительной информации доступной только в рантайме. Во-вторых, обычно на всю систему запускается одна виртуальная машина, для множества приложений использующих её, в то время как каждая программа скомпилированная статически тащит необходимый рантайм каждая свой. На самом деле это несущественно, но стоит упомянуть. И почему, к примеру, если я хочу использовать в своей программе систему классов NET Framework, я обязан перейти на виртуальную машину? Что, если я хочу, чтобы мой код компилировался в машинный? Тогда вам наверное не по пути. Например, мой одногрупник решил писать на Java, мотивируя свой переход с плюсов на яву тем, что в C++, якобы, нужно иметь дело со "всеми этими указателями" (и он даже ничего не слышал ни про RAII, ни про smart ptr'ы), а в Jave, вот, есть GarbageCollector, и ни о чем думать и заботиться не надо. У вашего одногруппника очень здравая позиция, он выбирает функционал и избегает лишней сложности. Это ведь великолепно, что GC снимает часть головной боли с программиста. А то что повышается потребление ресурсов, то это имеет значение лишь в том случае, если ощутимо заметно для пользователя. В остальных случаях -- это серьёзная оптимизация времени программиста. В чем же причина такого массового распространения managed языков, Видимо потому что программы исполняющиеся на виртуальных машинах легче переносить. Кроме того обычно такая среда предоставляет возможность работы с кодом как с данными, предоставляет большую гибкость. какую нишу они занимают, и какая судьба в будущем ждет языки вроде С,C++, Haskell, и т.д.? Си похоже не умрёт никогда. Haskell, как жертва постоянных экспериментов и исследований -- тоже. Зато C++ очень даже может сдохнуть, ибо слишком сложен, и преимущества не стоят недостатков. UPD: Нашёл очень занятную дискуссию. Внезапно обнаружилось что реализация языка Lua, LuaJIT выполняется быстрее чем код на языке D. При том, что язык D -- статически типизированный, компилируется в нативный код, тогда как Lua -- динамически типизированный, с JIT-компиляцией. Такие дела.
Комментариев нет:
Отправить комментарий