зачем нужны интерпретируемые языки?

[Utkin]

только вот малое НО, реализация того же в виде функций будет работать так же.

А как же расходы на RTTI?

[western_digital]

Сообщение от pu4koff

Синтаксис у всех этих языков некрасивый. Логика местами сомнительна. Основные принципы недалеко от всяких плюсов ушли и принципиальное разницы нет.

Разница есть: в обычных языках ты мучаешься с компиляцией, дефайнами, хедерами. А в интерпретируемых ты просто бёрёшь текстовый документ и пишешь код. Более того, в этих языках много упрощённых реализаций массивов, ассоциативных списков и прочей шелухи, которая реально всё ускоряет.

[pu4koff]

Сообщение от Пепел Феникса

виртуатуального лишь.
только вот малое НО, реализация того же в виде функций будет работать так же.

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

Сообщение от western_digital

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

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

Сообщение от western_digital

А в интерпретируемых ты просто бёрёшь текстовый документ и пишешь код.

И на плюсах берёшь текстовый документ и пишешь.

Сообщение от western_digital

Более того, в этих языках много упрощённых реализаций массивов, ассоциативных списков и прочей шелухи, которая реально всё ускоряет.

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

[Utkin]

В шарпе вот с каждой версией плюшек прибавляется, у плюсов и делфей просто какие-то другие направления развития, но и там чего-то по мелочам улучшают.

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

[Пепел Феникса]

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

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

в шарпе на многое расход больше, за счет продвинутого RTTI и функций его юзающих, но в С++ он довольно слаб.

при вызовах методов, максимум будет обращение к VMT, что довольно быстро.


а уж если с интерпритацией сравнить...

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

что такого эти хелперы позволяют? разве не расширение методов существующих классов?

[Utkin]

что такого эти хелперы позволяют? разве не расширение методов существующих классов?

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

а уж если с интерпритацией сравнить...

Уже половина в байткодах работают, хоть на лету все равно быстрей.

[Пепел Феникса]

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

речь явно не про эту фичу, она в шарпе тоже есть как бы.

[Utkin]

речь явно не про эту фичу, она в шарпе тоже есть как бы.

Я же писал - Дельфи идет вслед чтоб "все как у людей"

[the_deer_one]

В .NET методы расширения появились как костыль для LINQ.

Все классы коллекций наследовались от интерфейса IEnumerable<T>.
А linq методы Select, Where, в интерфейс не вопхнёшь. Для этого надо было наследоваться не от интерфейса а от виртуального класса, который бы содержал методы linq. Но перефигачивать весь фреймворк не решились и вкорячили фичу, что бы вызов статических методов сторонних классов выглядел как вызов родных методов. В ФЯ оно вроде бы Composing Functions называется.

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

[Пепел Феникса]

В .NET методы расширения появились как костыль для LINQ.

и что с того что они были созданы и для LINQ?